The Messy Nature of Product Development

Building products is messy, uncertain, and non-linear. I’ve always found trying to explain this to someone who hasn’t experienced it difficult.

There are the typical ‘Dual Track’ pictures trying to depict this:

Credit Left: Jeff Patton, Right: SVPG

As well as others, like this more recent one from Jeff Patton below (from when I took his Passionate Product Leadership course a few years back), which I highly rate.

However, none seem to truly capture the messy nature of building products.

Credit: Jeff Patton. From Jeff Patton’s Passionate Product Leadership course

Instead, I’m often faced with correcting assumptions and perceptions based on these visualizations:

Discovery being viewed as ‘big-up-front-design’ that happens before development.

• Or that discovery and delivery are two separate teams

• “This just looks like another version of waterfall?”

I’m forever interjecting with “but… but… but” and clarifying, which is fine but not ideal.

The better we can articulate and clarify, the better we can influence.

After several iterations over the years, I’ve recently started to sketch product development like this:

So what’s happening here?

Well along the top we have three types of work: Discovery + Design + Development.

Why 3?

Because whilst design falls under discovery, I’ve found that a common question is “how does ‘design’ fit?”. So pre-empting that, over the years, I’ve found the following to resonate better with most people:

• Discovery = learning

• Design = shaping; and

• Development = building.

An idea will start with discovery.

This could be discovering the opportunity in the first place (exploratory discovery), or it could be learning more about it and testing our assumptions. Regardless, the cycle starts with discovery (learning).

As we learn more about the idea, we begin to design it.

This is where the notion of problem vs solution as a dichotomy is false.

As we learn about the problem, it shapes the solution and visa versa.

For example, knowing that people have a problem selecting gifts for loved ones is one thing, but as you shape the solution, you’ll likely come to realize that price, personal preferences, availability of stock, location and what stores are nearby all have an impact (it was Father’s Day in Australia last weekend, so either availability bias or perhaps a personal struggle - sorry Dad!).

Now yes you can consider all these things as part of the problem space but solution could involve who are we able to integrate with (stores), can we determine geo-location (availability of stock) or even how in the hell are we going to solve for ‘personal preference?’

Thus we shift back and forth between these types of work - we learn a little, design a little and we learn some more.

Things then get more complex. We may decide to build an early prototype of proof of concept. In fact, we may decide to proceed and build the first ‘version’ of the idea. As we do that, we’re going to learn a lot more bringing us full circle back to discovery and altering the designs.

Through each pass we add fidelity.

Fidelity in terms of the final product, as well as, fidelity in our understanding - which is where the Y axis comes in.

For example, at the very beginning, all you have is a very high-level idea - or not even - just a ‘gut feeling’ that this is a problem.

Over time your understanding of the idea increases. You then start to turn that understanding into a solution (fidelity increases).

For example, at the start, the solution is murky - perhaps all it is at this stage is a ‘back of the napkin’ sketch. Over time, as you learn more and design more, that sketch turns into wireframes and eventually into proper designs.

The same happens for development. It starts as no code, then a single line of code, and so forth. Eventually, we have a working prototype and then a final solution that we will launch to the market.

But wait, it gets messier!

Because none of this happens sequentially.

Yes, we may start with discovery and increasing the fidelity of our understanding, and as that happens we start to increase the fidelity of the design and the solution too. We then turn those designs into code, and so forth. Sounds neat right? But it’s not some big-bang approach where you discover, then design the whole thing and then build it. Rather it happens in iterations.

In other words, we can have ‘just-enough' of an understanding to build a wire-frame which may be ‘just-enough’ of a design to start to build an initial prototype - and repeat.

You might be thinking, if that’s the case then why does the sketch taper off towards the right? Shouldn’t it continue like at the top?

Well, because over time we will eventually either learn enough to stop investing in discovery or we have exhausted the things we would want to learn.

Of course, there’s generally more we can learn, more we can design, and more we can build. But there’s a point of diminishing returns.

Thus, over time, we will eventually taper off with discovery and design and only have things to develop remaining.

The ‘JED’ (just enough discovery) tool to help teams appropriately time-box discovery

The final thing you will notice in the sketch is that it’s not a perfect spiral down. We don’t linearly add fidelity, either. There are loops. Meaning that things go back ‘up’.

Yes at times we may go back in fidelity. This is often the case when we travel down one path only to learn that we need to pivot.

Messier again!

Some can view this part of the process as waste, but it’s far from it. It’s the process of innovation and creative work.

Imagine a painter who sketched something only to realize that it made the painting look cluttered. They would erase it, and try something different. True waste would have been sticking with the original concept and ending with a less superior painting that looked cluttered.

There are a lot of reasons why this aspect is hard for some to grasp and arguably a hard pill to swallow - I spoke with a founder the other day who shared how disheartening it is to have “spent money on a whole bunch of code that nobody wants” but it’s a necessary by-product of creative work - which product development is - so expect to bring out the eraser occasionally!

Of course, we want to minimize waste and how often we bring out the eraser - we also want to make those pivots cheap and easy to do - after all erasing pencil is much easier than paint! This is why we start with low-fidelity and discovery and design - that’s the product equivalent of pencil. And to further safeguard ourselves when we do turn it into code, we build in iterations, increasing fidelity as we go - we don’t build it all at once.

Embrace the mess and happy product building! 🚀

---

Need help with the messy nature of product? I can help in 4 ways::

1. Level up your craft with self-paced deep dive courses on specific topics such as Prioritisation, Stakeholder Management and more.

2. Free templates and guides on Product Pathways.

3. 1:1 Coaching/Mentoring: I work with product people and founders through 1 hour virtual sessions where I help them overcome challenges.

4. Private Workshops and Training: I frequently run private workshops and tailored training courses for product teams globally. Get in touch to talk about your unique training needs.

---

Top Posts