Product Management Dilemma: Explore to Build or Build to Explore?

As a product manager, do you explore to build or build to explore? This is an interesting question that I saw on my Twitter feed. Let's explore this one further. No pun intended!

Two extremes: on one end, there is building high fidelity artifacts before knowing the product-market fit. Well, Quibi is one recent example. On the other end, you're primarily dealing with Powerpoint decks, analysis paralysis with no end.

To explore anything requires a certain quality to your thinking as a product manager — learning with an open mind. You cannot keep exploring forever if you live in a real-world like the rest of us with financial, personnel, and market pressures. Shipping cannot be overemphasized.

Product Management: Knowns and Unknowns

You may have heard about these three categories while brainstorming ideas or concepts. If not, this is a good model to use --

1. Known knowns: Less risky, well-known, or otherwise validated.

2. Known unknowns: Identified, and they are in your organization's consciousness.

3. Unknown unknowns: Well, you don't even know about them, let alone exploring.

As Melissa Perri suggested in her book, a Product Manager has to be focusing on the second and third categories listed above:

Product Management is the domain of recognizing and investigating the known unknowns and of reducing the universe around the unknown unknowns. Anyone can run with solutions based on known knowns. Those facts are readily available. But it takes a certain skill to be able to sift through the massive amounts of information and to identify the right questions to ask and when to ask them.

Why Explore or Build?

But, why bother exploring or building? If your answer is to ship the features and delivery-focused, think again. The north star for exploration and building has to be all about value. What value will your work generate for the customer and the business you’re driving (or serving)? Both may not be possible every time - driving value to the customer and business, along with keeping a keen eye on viability. As I said, that ought to be the focus.

See these prior posts on more discussion around value: Jobs-to-be-Done: Your Go-to for Product Management and Strategy and Finding Product/Market Fit.

You may not achieve it in one try, and perhaps even striving for that is not desirable too. Once you have a value proposition as a hypothesis, you want to find out how valid it is as soon as possible.

Low-fidelity validation

This may be controversial in the product management circles, but your first goal has to build as little as possible to test the waters. The term MVP has been abused quite a bit. Let's bring it back into the sphere of sanity: minimum viability is not in scope alone but also building. Building anything non-trivial is expensive. When the concept is not proven: go ahead and build as little as possible and leave plenty of manual interference in the workflows.

What you're doing here is building only that much to explore further. Test the market, seek user feedback, and see which pieces resonate and which ones are duds.

So which one is it explore first or build first?

I see exploration and building pretty much intertwined. Keep exploring and building later will have a lot of opportunity cost to it, along with the waterfall frame of work.

Focus on building for several months without exploring (or introspecting) is a recipe for disaster.

Keeping short delivery cycles and focusing on value will lend a nice balance between building and exploration activities. Anything else is shooting in the dark.