Break Outcomes Down, Not Initiatives

Hey I’m Ant and welcome to my newsletter! I write actionable posts on product, business and leadership to help you grow your product and craft.

You might have missed these recent posts::
- Building Greater Role Clarity
- The Adjacent Growth Strategy
- Asking Better User Interview Questions

My day job is advising companies on how to install a product-centric operating system. My evening job is helping product mangers master their craft through Product Pathways.

---

While incremental development is a great tool in our toolkit, it's focused on breaking down the solution, not the problem.

I’ll explain what I mean.

Incremental vs Iterative

By no means is this an either-or. We should be leveraging both incremental and iterative approaches to the way we work.

The trick is knowing which is the right tool for the job and when to apply them appropriately - I still see teams make this mistake, so let’s get into it!

Incremental Development is taking something and breaking it down into smaller components.

Think of a puzzle. The final design is already decided, but it’s been broken up into hundreds of pieces. We need to put the puzzle back together one piece at a time.

Iterative Development on the other hand, is much more experimental. It’s trying something to see if it’s a step in the right direction, if not we scrap it and try again.

Iterative development is more like painting. You have an idea of what you want, but ultimately, how the painting comes together is much more a process of trial and error.

A common pattern I see in many of the product teams and companies I coach is that they’re doing a lot of incremental work but little-to-no iterations.

They have this big idea (often framed as an initiative) and become solely focused on breaking it down. The initiative becomes a series of epics, and that epic becomes a series of user stories, and so forth.

Now, this is great when you’re trying to achieve is something large - like moving from one infrastructure to another. For example, a lot of my enterprise clients are doing work like moving to the cloud; this is ideal for the incremental approach).

However, the problem arises when they apply this approach to all their work.

Now, you might be thinking, well, the real problem is that these teams are actually project teams delivering solutions, not true product teams who are empowered to solve problems.

And I wish it was that simple, truly!

I still see this behavior even when teams are given problems to solve.

Often, the problem the teams are given is still quite large, and the team immediately jump into solution mode. They themselves come up with ‘big idea X’ to solve problem Y or Outcome Z.

While it looks a bit better at the top, the same pattern is repeated.

Side note: another sympton I see when teams operate this way is that they have long backlogs. Backlogs full of descoped work from their v1 (or so-called MVP) earmarked for v2 or a future release.

Break down the outcome

A good habit to build is to see if you could break down the problem first rather than the solution.

I don’t typically see too many teams do this.

For example, say that the problem space you were exploring was to increase the number of successful onboarding (if you are working in the outcome model, perhaps your ​OKR​ was to have x% of new customers complete onboarding).

Now, you can imagine that there are several steps to onboarding, and each step likely has its own challenges (e.g. drop-off rates) and opportunities for improvement.

To illustrate what the ‘breaking down the work first’ (aka incremental) approach would like:

The team take on the 'hairy problem'. They immediately launch into a long discovery cycle where they conduct several user interviews, dive into the data and conduct rigorous user testing to uncover all the potential problems and opportunities to improve onboarding.

Their output is a large ‘initiative’ that contains all the onboarding improvement opportunities that they found.

The work is then broken down into incremental improvements to the onboarding process - “we will do X first and then Y and then Z.”

Now, don’t get me wrong, the outputs from this are generally fantastic work.

It’s often beautiful user journey maps with all the pain points, feedback and potential solutions mapped.

Circa 2017: Our user journey printed on the wall (screen-by-screen) with user feedback on post-it notes.

But there’s a time and place for this approach. For example, this would work well if we were doing a complete redesign.

However, if the goal is to increase the % of users who complete onboarding, then a more iterative approach would typically be better suited.

So what does that look like?

Rather than coming up with solutions for the entire onboarding process, the team break the problem down first.

The team first look at any available data and feedback they already have on the onboarding process. Looking at the click-through-rates (CTR), they identify that one section of the onboarding flow has a significantly worse CTR than the rest.

Based on the data the team decide to hone in on that part of the onboarding flow - "if we can improve the CTR of this part of the flow, then we should be able to increase the overall number of people who complete onboarding"

The size of the problem has now been significantly reduced.

Rather than chasing ‘improve % of users who complete onboarding’, we're now focused on ‘reducing drop-off at point B by x%.’ or 'increase CTR at point B to Y%'.

The number of solutions we can come up with to ‘reduce drop-off at point B’ is much less than that for the entire onboarding.

Visual Example of breaking down the outcome/problem space.

Conclusion

I really like this framing from John Cutler; “Think big, work small”.

This is what you’re trying to achieve.

Break the problem/outcome down to first, make that small, and then make the work fit the smaller problem. Rather than increasing the size of the work to fit the larger problem.

The benefits of working this way means that you’re:

• Working smaller

• Your product backlog remains shorter (it doesn’t become a dumping ground for v2, v3, v4…. etc….)

• You experiment more

• Work is immediately measurable; solve a small problem and see if that moves the dial on the larger problem

Remember that we need to shape outcomes, opportunities, and solutions - and really should approach product work in that order.

p.s. For what it’s worth, my personal principle is always to challenge whether we can break the outcome/problem space down first. Only fall back onto increments when we cannot break it down anymore, and we still need to ‘work smaller.’

---

Need help with scaling your product or business? I can help in 4 ways::

1. Level up your craft with self-paced deep dive courses, FREE events and videos on YouTube, templates, and guides on Product Pathways.

2. 1:1 Coaching/Mentoring: I help product people and founders overcome challenges through 1-hour virtual sessions.

3. Consulting and Advisory: I help companies drive better results by building effective product practices.

4. Private Workshops and Training: I run practical workshops and training courses for product teams globally.

---

Top Posts