Photo Credit: Jamie Street

The Discovery Process is the First Step in Developing a New Product

In this post, we will dive deeper into the Why, the What, and the How of discovering what to build.

Why Go Though a Discovery Process

We have found that starting with a structured Discovery Process leads to successful and sustainable products.

Your goal should be to start small and make consistent, incremental progress.

This works like setting anchors to secure the rope as you climb a rock wall: if something does not go as planned in a sprint, you can only fall down to the prior level of solid progress.

The Goal 

The goal of this process is to take your vision as a Product Champion, and turn it into a plan that will improve your odds of success.

Start with your imagination, what you see and feel when you squint into the horizon, and help make this vision actionable.

A Note on ROI: Make Sure the Payoff is There

Before starting a Discovery Process, you’ll want to make sure that there is at least 10x ROI in the project (preferably multiples of that). 

This ensures you are solving a meaningful enough pain point for your business or your customers. You’ll need that motivation when the going gets tough, as it almost always does.

Innovating into the Unknown

Building B2B software is hard. You are, by definition, doing something that has never been done before. If a solution were available in the market that addresses the pain point you have, you would be using that solution instead.

That’s the dark side of innovation…you are stepping off into the unknown.

The goal of the Discovery Process is to help you, as the Product Champion, to crystallize your vision and insights to their very essence.

This crystallization process makes users and their pain points specific and acute – and therefore, solvable. Notice we did not say easy :)

The quicker you get to a Minimum Viable Product (MVP), the sooner you can enter the Build-Measure-Learn cycle and start to make steady progress

Who is the User?

As a Product Champion, you probably have a hypothesis about the user of the product.

Note that you as the Product Champion may or may not be the end user of the product. The user could be out in the field, or it could be someone else in the organization.

The first task is to determine who is the one user with the most pain right now, AND to overlay these insights with the highest-impact use case. 

High-impact use cases are measured by the magnitude of the pain of the user, AND the magnitude of the impact if you were to solve that pain.

Yes, you may have more than one specific user in mind, but you have to start with one. This is the discipline that will lead us to realize the product vision together.

You can still create a list of other users that the product could apply to, but you always start by focusing on one user.

All other users will be temporarily stored on the The Shelf of Good Ideas You Won’t Do (Yet). More on this later.

The Art of Listening for User Pain

Listening for user pain is as much art as it is science.

Interpreting the answers is nuanced. The more interviews you do, the more data you have, and the more you can have confidence in your user hypothesis.

There is the pain you hear about the most. The one that keeps coming up. But common does not always mean acute.

You want to understand the magnitude of each pain point on two dimensions: 1) Impact to that user, and 2) Impact to the organization.

A pain that is heard less often but has a larger downstream organizational impact may be more valuable as a starting point than the pain point you hear about the most.

The MVP: Shedding Features to the Most Essential

One of the hardest things about building software is having the discipline to decide:

What 9 out of 10 good ideas are you not going to do right now?

To paraphrase Steve Blank of Four Steps to the Epiphany, no product ever survives first contact with actual users.

You want to start learning from real user feedback as soon as you can, so one of the crucial decisions you will make is:

What is the absolute bare minimum feature set that will address the pain point of the user?

It won’t (yet) have all the bells and whistles, it may not work on mobile, or it may not quite work or look the way you want it yet…but the goal of the MVP is to start learning.

Which means leaving some ideas on…

The Shelf of Good Ideas You Won’t Do (Yet)

Ideas are great. We all have them, and many of them are good!

But good idea does not always mean good idea right now.

That’s why you should have a device called The Shelf of Good Ideas You Won’t Do (Yet).

In the context of the Discovery Package, this could mean additional users, it could mean more features, or it could mean other areas of the business where the new product could also make an impact.

In product development, discipline matters. There are many ways to take the use case of one user whose pain has been solved and then add more users, features, or use cases as the process progresses.

In our experience, we have not seen successful products that started out by addressing the needs of multiple users at inception.

Peter Thiel puts it most succinctly when he talks about the importance of starting small.

He points out that Amazon started with books, and eBay started with Pez dispensers…you have to focus on finding the small initial wins together (which you can build on later).

Architectures, Project Plans, and More…

In addition to crystallizing users and their stories, you want to make sure you are planning within your organizational constraints.

This is where existing systems, data sources, cloud preferences, and other technical requirements come in.

Our Why

We exist to bring product innovation to high-impact situations.

We have worked with the largest companies in the world, cutting-edge startups, and industries new and old.

If you see yourself in these ideas, we would love to hear from you!

Why We Do Discovery Packages

Successful, lasting, and mutually beneficial engagements are the core of our business ethos.

Product discovery, build-out, and scaling is what we specialize in.

We help bring an unbiased observer perspective. Free of the history of the idea within the organization.

Also,

  • We have done it before
  • We know what to listen for
  • We ID and isolate a pain point, and match it to a technical architecture and a project plan
  • We adapt to your stack while using cutting-edge tools

Starting with Makepath’s structured process of co-discovery leads to building alignment that will last throughout the process.  Alignment leads to trust, trust leads to strong partnerships. Strong partnerships build effective solutions.

At Makepath our objective is for you to launch the most effective solution possible, in the most efficient method possible.

The Discovery Package is a crucial step that allows us to craft a solid foundation, enabling you to build the most resilient software structure

We will conduct user (and stakeholder) interviews together, anywhere from a handful to over a dozen, depending on the situation.

Yes, we have a set of questions we have refined by doing this over the years. Happy to share the list if you reach out at contact@makepath.com.

We also want to deliver a project plan to you that is valuable with or without Makepath.

We want to earn your business, but if you decide you want to take the plan and build the product internally or with another firm, you can do that.

The Discovery Package deliverables include:

  • Project Scope Outline
  • User Persona
  • User Stories
  • Technical Requirements
  • Architecture Diagram
  • Project Timeline
  • Project Assumptions
  • Recommended Cost Appetite
  • Risk Assessment

If you’d like to see a sample deliverable, please reach out at contact@makepath.com.

Credit for These Ideas

We have earned many of our lessons over 15+ years of building products.

We have also picked up wisdom from others along the way…here are a few resources you may find valuable: