Mind the Product Delivery

Why delivery is still important in the age of product discovery

Over the last years we witnessed a mind shift in the product community: The focus used to be on product delivery — the process of building releasable software in the most efficient way. Nowadays, the spotlight has moved on, though. Product discovery, the quest of figuring out what to build in the first place, has become the state-of-the-art way to craft products. A discovery mindset is advocated by the great minds in the field and is placed at the heart of popular concepts like Design Thinking and Value Proposition Design.

I do believe that this focus on user centered innovation and idea validation helps to create amazing products. Yet, with the obligation to discover unmet user needs, we must not forget where we came from. Sure, the creativity and energy-laden discovery phase can make the detailed and structured delivery work feel dull. Ultimately, we still need to deliver and bring value to our customers and succeed with our endeavors.

It’s not about choosing sides

Sure, discovery is different to delivery. The former seeks openness to discover and validate new ideas. The latter is about deep focus on the task and tries to deliver value to users as fast and smooth as possible.

With the latest buzz around creating discovery driven organizations to escape life in the feature factory, it sometimes feels like we need to choose sides. There is no either-or decision to be made here, though — both phrases have their Raison d’Être in the product development process and should be used situational, not mutually exclusive.

Dual Track Development framework by Jeff Patton, Source

Jeff Patton, author of User Story Mapping, coined the term dual track scrum in which validated learning from the discovery phase eventually ends up on the delivery track. To ship items in a fast and focused way, there need to be continuous shifts between exploration and delivery. It might even be that teams need to get into delivery mode during their discovery when low fidelity prototypes do not cut it anymore and a test requires a larger amount of work.

Don’t keep them waiting

When the handover into delivery mode is made, you benefit from the focus on getting work out into the world. Retaining this willingness to deliver to users is as important as understanding them better. It creates a sense of urgency ensuring that what was learned in the discovery is processed into actionable development items. Having this urge to deliver prevents the discovery death spiral in which a promising idea circulates in research phase missing the exit to become an actionable product concept.

Highlighting the important areas of product delivery in the discovery process

Moreover, user value will not solely come from discovery insights. In larger teams, there is a fair chance that not every member is fully stretched with doing discovery work. This gives the opportunity to ship additional improvements. However, filling this downtime gap with value might be easier said than done as the people required to finalize the work packages— designers, product owner, lead developer — are more involved in the discovery. Thus, keeping actionable chunks of work prepared for delivery is important, so that user value can be created in parallel to the discovery.

When in discovery mode, we are taught to think of “wicked ideas” trying to help users solve their problems in a whole new way. Not all work needs to be game changer material, though. Even if you are just giving your users something small, this value is instant. With discovery work, even though its outcome aims at producing much higher value, it might take a while until your idea is ready. And even then, the development process is iterative and first deliverables are mostly only rolled out to test groups first. We should thus not underestimate the time it takes for discovery value to reach our users and that it’s worth preparing to deliver valuable work to users in the meantime.

Bathing in uncertainty is not for everyone

Focused delivery can also have a positive impact on team members who are not yet used to live the new discovery driven approach to building products. Tom Chi, Google X Co-Founder and prototyping evangelist, stresses that product management is all about uncertainty. You have to embrace it to a level where you enjoy the regular uncertainty baths during your quest to uncover what users really want.

Ultimately, discovery helps you manage and master uncertainty. Still, finding an established discovery mindset in an organization is rare. It requires a change of thinking, going away from set plans towards an openness to new ideas. Only a few companies have mastered this shift so far. So if uncertainty baths are not part of a company’s DNA, how can you expect every member in your team to feel comfortable with it?

As someone who entered product management motivated to take a deep dive into the uncertainty pool, this wasn’t obvious to me at first. Not everyone looks forward to the unpredictable and spontaneous nature of product discovery. I saw colleagues excel in their role, producing highest quality work constantly and quickly, when they had a concrete and plannable task given to them. In the uncertainty driven discovery phase it is important to keep these individuals in mind to spot potential frustration with ever changing plans early. Clearly defined delivery tasks can keep the motivation high, while ensuring high quality work at the same time.

Don’t forget the delivery, man

A constant change between discovery and delivery allows teams to enjoy the best of both worlds — validated user needs combined with a focused delivery of valuable functionality. We should not forget about the importance of the latter with the current buzz around the former.

Without proper delivery, all those customers that you interview might never get their problems solved… or at least not by your product.

If you liked reading this, please click the ♡ below to help share with others. This small and kind gesture keeps me motivated to write more articles like this one.