How do you build a bare minimum feature?

Have you ever felt it was difficult to ship on time?

Isn't it true that understanding what works is nearly impossible without having to build and ship different solutions to understand which one works?

Is there any better advice than to "ship it before you're ready" in order to learn more quickly from the people you serve?

Feature development is a virtuous cycle of going from a problem to an idea to then build, launch and learn. But this is a very expensive form of development because the chances of being wrong are very high; the time, effort, and resources spent developing a big feature to get to the insight are wasted if it doesn't resonate with your customers after months of development.

But failure is a data point to evaluate and ask "is there a better way to make progress towards mitigating the risk of building the wrong thing so that you can gain enough confidence that it will be adopted by customers?" The answer lies at the beginning of the product development process. At the heart of the customer problem.

So far your instinct as product designer/manager/engineer might be to take what customers say they want at face value. Then you build it and launch it, only to find that it doesn't quite work, and you're back to square one. It then becomes critical to ask the right questions during customer discovery calls in order to determine how to reduce the risk of building the wrong thing.

The goal in a discovery call is to:

1. Understand what their overall journey was to ask for the feature
2. How did they discover that it was important to them?
3. What event prompted them to reach out and ask for the feature?
4. How satisfied are they with the current way they're doing things to make progress?

What you're searching for is a pain in the form of unmet needs where they aren't sufficiently satisfied with their current process. It's important to note that if they aren't doing anything right now to make progress toward completing their task (whether through an external product or a manual process), it's possible that it isn't a real problem worth addressing.

What questions do you specifically ask then?

First, understand the context behind where they started to struggle

Ask questions such as:

• Can you tell me a little about how you got to needing this feature in the first place?
• Can you tell me about when you started thinking that maybe this feature (their idea) could be used to solve the problem? Why are you doing this now?
• What's not happening that you want to happen?
• Where's the frustration?

Second, understand what they're doing right now to progress

Ask questions such as:

• What other tools or things have you done manually to try to do this?
• How satisfied are you with this process/tool?
• Where's your frustration?
• What don't you like about the current way of approaching this problem?

If possible try to observe how they go through it right now by asking them to show you.

Third, understand where they want to be (the ideal outcome)

Ask questions such as:

• Can you walk me through a little bit on what the end result you’re trying to get to is?
• What are you hoping for?
• What's going to be different once you've got [the new feature] in your life?

Knowing the answers to these questions will help you form a bounded bare minimum solution as well as tell you what not to build. You will have a clear understanding of where the customer is in relation to time: the point at which they begin to struggle and what they want to achieve.

Check out these references on how other companies came about this problem:

• Building a worse map at Intercom
• Ben Orenstein on his experience building dual mouse cursors at Tuple.

References

• A special thanks to Michele Hansen for writing Deploy Empathy, some of the questions to be asked came from her Switch Script.
• Some questions came from Bob Moesta's Book Demand Side Sales under "Progress Tools". You can read my notes or get the book if you'd like.