On researching the competition…

A research minded Product Manager, if a competitor just launched a new product, they go out and talk to users right away: “what does this mean for you?”, “how does this fit into your life?” They’re looking for those opportunities to discover new things rather than sitting and saying “we need to get to feature parity with them right now”.

Because customers don’t really care about feature parity, everything is part of an experience, part of a journey, and Product Managers who excel at research are always proactively seeking out that new information, those new challenges and looking for ways to activate that before someone tells them to.

– Matt LeMay on The CORE connective skills of product management (podcast)

I like this framing of competition research as digging into the problems a competitor is trying to solve, rather than copying their implementation. The deeper thinking suggested here seems likely to turn up ways that your company can improve on the solution, make it your own, or perhaps even determine that this opportunity is not necessary or not a priority for your customers.

Measuring software productivity (cue teeth sucking)

In the A16z podcast episode on “Feedback Loops” they talk about the controversial, and frankly just tricky, topic of measuring productivity. I found the whole episode interesting, but you might want to listen for 5-10 minutes from about 20:00 minutes in or just read my notes and trust I’ve heard them right 😃

My notes:

  • Don’t use Lines of Code to measure productivity, you end up with pointless lines of code
  • Don’t use agile velocity (i.e. story points burn down), these are more a measure of effort for capacity planning purposes (and they can be gamed)
  • The interviewees (Nicole Forsgren and Jez Humble) recommend:
    • Lead time (code commit to code deploy) – they talk about this as an “outcome” not an “output”, but I’m not sure I entirely follow here, though I do see it as a measure of the whole team’s ability to deliver value (assuming that’s what the code commit delivers) to a client
    • Release frequency
    • Time to restore
    • Change fail rate
    • …but Nicole and Jez admit there are gaps here in measuring if the change delivers value (i.e. effectiveness, efficiency, customer satisfaction, delivering mission goals)

I wonder if there’s a “time to positive outcome” metric (using the outcomes defined when the opportunity was identified), which would encourage tight iteration to allow frequent course correction? Measuring a team on the outcomes they themselves define when the opportunity is identified requires a team of high moral fibre, as there’s a possibility to game it right there.

Photo credit: © Travis Wise, 2014, Dials and Gauges

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.

I’m reading about… Product Managers

At WordPress.com VIP we're looking into more formal Product Management, to help ensure that all our teams are aligned behind a consistent vision and a clear set of priorities. As such, I've been reading around about the Product Manager role to understand best practices from other organisations and from leaders in the field.

As one of the founding parents of modern software Product Management,  I found Marty Cagan a good place to start:

I want [Product Managers] to understand they need to worry about all aspects of the business, but I also believe strongly in the importance of humility for a product manager, and I need to make sure they’re not thinking the title gives them anything beyond a shot at earning the respect of their team.

– Marty Cagan, My Favorite PM Interview Question

Are you just administering the backlog, or are you actually tackling and solving difficult problems for your customers and your business?

Marty Cagan, Product Manager vs. Product Owner Revisited

There's a phrase which originated with Ben Horowitz's post Good Product Manager/Bad Product Manager, "the CEO of the product". It's a phrase I initially railed against in my reading, particularly in context of our Automattic culture which values independent, self-motivated, and extremely capable individuals. In my initial thinking I was leaning more towards a collaborative model, but the Marty Cagan posts above (and some key chats with others in my team) have turned me around, and now I see the value of the responsibility and strong links between the measure of the product manager and the success of the product.

Horowitz points out that his Good Product Manager/Bad Product Manager article was written many years ago, but even with that perspective it's worth a read:

Good product managers know the market, the product, the product line and the competition extremely well and operate from a strong basis of knowledge and confidence. A good product manager is the CEO of the product. A good product manager takes full responsibility and measures themselves in terms of the success of the product.

Ben Horowitz, Good Product Manager/Bad Product Manager 

Rarely do any delivery functions report to the Product Manager, meaning Product Managers are dependent on others to deliver the product they are measured on. A fact which is emphasised in this line from one of Marty's quotes above: "I need to make sure [Product Managers are not] thinking the title gives them anything beyond a shot at earning the respect of their team". This tension is felt keenly in some of the articles I've read, in particular:

…you are not the CEO of anything…

This may seem like mere semantics but the distinction is important. Too many product managers I meet buy into this trope of CEO-of-the-product and believe their role is to act like an authoritarian CEO, often with disastrous results. These product managers tend to believe they have all the answers, that they produce the best solutions and designs, and that their teams should just do what they’re told. They’re mini-CEOs after all!

…Truly successful product leaders instead embrace their lack of authority and lead their teams and the wider company through communication, vision, and influence. They focus on collaborating across the company, bringing together the best people to move the product forward, and setting those teams free to execute on their product vision.

Martin Eriksson, Product Managers – You Are Not the CEO of Anything

Having re-read the Eriksson and the Cagan posts, both seem to me to be arguing for very similar positions: leadership without authority, and closely linking the success of the product to the measure of the Product Manager. The reference to CEO is a positive assignment of responsibility, not a licence to a command and control style of leadership.

More on Product Management as I find it; as my honoured colleague John Maeda says, "I'm learning".

A Hot Toddy

I went with 8 oz hot water, a twist of lemon, 2 cloves, juice of a lemon, a generous teaspoon of honey, a small stick of cinnamon, and 2 oz Talisker; the end result was almost too medicinal, for which I side eye the Talisker, but a definite balm and I’m now off to bed.

Inspired by Nigel Slater, and my friend Zé (I’ll try the Apple juice next time, Zé, I had none in). I also avoided the prevalence of tea in recipes online (thanks due here).

Trump: The Presidential Precedents, Andrew Jackson

To the east coast establishment he was an uncouth demagogue, to his supporters [two term US president, Andrew Jackson] was the tribune of the people, the embodiment of white masculinity.

– BBC Radio 4 – Trump: The Presidential Precedents, Andrew Jackson

I know little about US history, but this short Radio 4 programme yesterday caught my attention. The programme focussed more on Jackson’s “colourful” campaign, and little on his policies beyond a brief mention of the Trail of Tears and the destruction of The Bank of the United States; but one thing that struck me was that despite how his opposition mobilised against him, he won a second term. How does this section of history inform our view of Trump, I wonder.

Interesting too that Jackson is considered the founder of the Democratic Party.

Political Scrapbooking 

… the notion that large numbers of pro-Brexit voters are experiencing buyer’s remorse is both unproven and irrelevant. … And it is hard to avoid the feeling that much of the Remain camp disappointment comes from people who are simply not used to losing votes that might negatively affect their own lives. As Manchester Professor Rob Ford put it, the English middle class is simply experiencing what UKIP voters have had to put up with for years.

Uniting the United Kingdom by Anand Menon for Foreign Affairs

As so often, political reality will trump the lawyers. Alan Renwick of the UCL constitution unit argues that there is now a political imperative for the next prime minister to hold a parliamentary vote before the invocation of Article 50. But it is hard to imagine that MPs would choose to overturn the majority decision of the referendum on June 23rd.

Who has the right to trigger Brexit? In The Economist

http://www.instituteforgovernment.org.uk/sites/default/files/publications/Brexit%20Options%20A3%20final.pdf

This is fascinating:

…by their silence Corbyn and his troubled, paranoid court have delivered us, in effect, and for the time being, into a one-party state…

Britain is changed utterly. Unless this summer is just a bad dream by Ian McEwan for The Guardian