Marty Cagan in London, April 2018

As part of diving into Product Management, I noticed that Marty Cagan of Silicon Valley Product Group was speaking at a Business of Software evening in London. Marty was recommended as a figure to follow by Brie, my colleague at Automattic, so I grabbed a ticket immediately.

Marty centred his talk around unleashing and empowering the engineer, and it was incredibly impressive and inspiring to listen to him. It’s always wonderful when you’re learning from someone with sufficient mastery of their subject that questions always trigger a well thought through response, backed up by multiple examples. Here’s my tl;dr for the evening:

Continue reading Marty Cagan in London, April 2018

I’m reading around problems, experiments, and solutions

There's a lot of product management talk at the moment about defining the product roadmap in terms of problems, rather than features or solutions. I will write up my reading on roadmaps another day, but today I wanted to collate and synthesise some of my reading on approaching individual steps, opportunities, and problems along the roadmap.

I recently watched the Bill Constantino's presentation, "Toyota Kata Unified Field Theory", it's ten minutes long and well worth your time. In the presentation, Bill outlines a method for moving from a current state to a solution, referred to as a "Target Condition", which is located outside our current area of knowledge; examples of a Target Condition might be to crack a new market, or reach a new level of efficiency. The method moves towards the desired Target State by identifying a series of problems between the current state to the Target Condition, pushing out the edges of the area of knowledge as you go. Eventually you have navigated a series of solutions, routing through what was unknown territory, and you are able to achieve the Target Condition.

Mark Rosenthal, on whose blog I found this presentation, summarises the process of the Improvement Kata neatly, and provides a nice animated GIF of the process (read the article, and you'll find the animation towards the bottom):

The process becomes one of progressively solving problems, identifying the next, and expanding our understanding. Once there is sufficient understanding to anchor knowledge and take the next step, do so. Step and repeat.

– Mark Rosenthal, Bill Costantino: Toyota Kata "Unified Field Theory"

So the path to a solution is to navigate feelingly across a field of experiments and related problems. Teresa Torres has related angle on "feeling navigation" with her Opportunity Solution Tree. The Opportunity Solution Tree starts with a clear Desired Outcome, like the Target Condition of the Toyota Kata. Working backwards from the Outcome, you identify a number of Opportunities based on your customer knowledge anchored in your customer research and contact. (In a recent Pragmatic Live podcast, Teresa describes how she prefers the term Opportunity to Problem, as Opportunity allows for finding moments of delight with one customer and bringing that delight to a broader audience. Interestingly the Bill Constantino presentation also avoids the more negative term "Problem"… something for me to ponder.) For each Opportunity, the team then works up a number of potential Solutions… and for each Solution areas of uncertainty or unknown elements are de-risked with targeted Experiments.

Start by defining your desired outcome. What’s the most important metric your team can impact? You want to pick an outcome that will drive the most value for your business right now.

Then start to enumerate the opportunities that might drive that outcome. Remember to stay in the problem space. If you can, do some generative research to frame the opportunities in the same way your customers would.

Finally, try to connect each of your solutions to those opportunities. If you have some solutions that don’t connect, look for a missing opportunity or set the solution aside. It’s a distraction for now.

Teresa Torres, Why This Opportunity Solution Tree is Changing the Way Product Teams Work

The whole article is worth a read and provides useful illustrations of the approach. In the article Teresa further describes how visualising the wider view of a team's approach allows that team to spot when they are overly focussed (jumping to a single Solution quickly, without considering alternatives or running sufficient experiments to check their direction), or overly broad and unfocussed (getting overly enamoured of the "infinite funspace" of all the possible Solutions for all the Opportunities, running many many experiments and never delivering value).

As I'm reading and musing how to apply these ideas in my own practice, I'm wary of imposing process and of becoming overly bound to that process. In Jeff Bezos' 2016 letter to shareholders, he writes:

Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right. Gulp. It’s not that rare to hear a junior leader defend a bad outcome with something like, “Well, we followed the process.” A more experienced leader will use it as an opportunity to investigate and improve the process. The process is not the thing. It’s always worth asking, do we own the process or does the process own us?

Jeff Bezos, 2016 Letter to Shareholders

Naturally, there are times when experimental method and process are largely unnecessary. In a recent episode of the Roadmunk podcast, Melissa Peri talks about the necessity of considering and experimenting to ensure that we are building the right solution, but acknowledges this is not always necessary:

For example, I like to use a checkout page. Checkout pages have been explored. People have experimented with them. There are pretty well-known best practices in the industry of how to create checkout pages. Maybe I take some of those best practices. I implement a checkout page, launch it, and start measuring to see my results.

Product to Product: Melissa Perri on how to think like a product manager

There's always going to be steps we need to take, elements we need to build, which are necessary prerequisites to providing value to our customer, but which are not able to really magnify or multiply the value provided. Foundational elements. For these, where they're well understood elements like a login page or checkout, it's fine to follow best practice.

Those key elements of our products, the elements which will allow us to provide value and delight to our customers, and propel us past our competition, these are where we need to consider our approach carefully to ensure we give ourselves the maximum chance of success.

Let me know in the comments if you have any thoughts or feedback on these subjects. I'm learning.