Lessons from MTPEngage Manchester 2019

(N.B. These are notes from my thoughts while people were talking as much as they are notes about what was actually said; I hope I’ve not misrepresented anyone though, and please call me out if I have.)

Nilan Peiris from Transferwise talked about Customer Led Growth, he mentors his teams to constantly remember the problem (fall in love with the problem, not the solution, sounds simple…) and to make big value bets with confidence rather than optimising incrementally (it seems nobody at Transferwise is playing with button colours).

Tom Loosemore’s challenge was around digital transformation in organisations, or “changing the weather” as he put it. Change is challenging, and those pushing for it should remember that this challenge can be emotional, for themselves and for others in the organisation. Tom’s big money slide, much tweeted, was this:

“If you’re not feasting you might be fired, you’re probably not being bold enough.”

I read this as a message that if you are explicitly choosing or charged to create change in your organisation you are going to ruffle feathers and cause a bit of a stir, to say the least. Tom addressed concerns over the privilege “if you’re not feeling like you’re about to be fired” that this slide has evinced for some:

For me, I found this message of feel the fear and do the right thing anyway inspiring.

“Obligatory Sun Tzu quote” 😆

A lot of my efforts at the moment are bent to understand and practice product strategy, so I was looking forward Nicholas Goubert’s talk on the subject. From Nicholas I took away that I shouldn’t be afraid of strategy, that “an imperfect strategy is better than none”, and that, as with almost everything, iteration was the key.

Product Strategy is cross-functional, so we need to work with other stakeholders to ensure that everyone is aligned and in sync. Product Strategy needs to be understood by everyone, so reiterate, reiterate, reiterate at every opportunity. Overcommunicate the strategy to promote ownership amongst the team. In his interview on Maggie Crowley’s Build podcast, John Cutler talked about being ready to “walk your belief map”, and this strategy of reiterating the strategy reminded me of that: “we’re doing X because we believe it will promote Y, which will get us closer to our organisation vision because Z”.

Nicholas talked a living strategy which was challenged weekly, and which you are not afraid to update, radically if required, every quarter. Vision, on the other hand, is an immutable constant. Happily share your vision externally, but keep your strategy internal and share only with stakeholders (although that may include customers). The Product Roadmaps Relaunched book talks about your roadmap being a prototype of your strategy, which Nicholas’ advice echoes.

Randy Silver reminded me us of this timeless quote:

The day we stop being curious about our customers is the day our competitors start to catch up.

– Theresa Torres

As well as a simple but important differentiation: don’t talk to your customers, listen to your customers. Aim to pick one tough, meaty question, a question which will get at the “why”, ask it, and then keep listening as your customers tell you their stories (from personal experience, this is harder to do than to say).

Randy also gave us a good Product Management description for when your relatives ask what you do:

I help people make better decisions faster.

– Randy Silver (although he credits Monika Turska)

Roisi Proven talked about closing the Lizard Loop, listening to your the System 1 (fast, instinctive, and emotional) thinking and backing it up with System 2 (slower, more deliberative, more logical) thinking. She recommended taking a baseline to start, considering what biases and anchors you are carrying, for example:

  • Do I think unfairly about a group?
  • Am I blindly or overly positive about my work?
  • How do I think and feel when users “get it wrong”?

Roisi recommends checking in with your lizard (System 1) and your owl (System 2) before coming to a conclusion. Feel the knot in your stomach, or the urge to optimism, and back them up with data before proceeding.

Roisi also reminded us that the world isn’t just nice people, and that when developing products we should always consider:

What’s the worst that could happen? …or, what if this, but baddies?

– Roisi Proven

…which reminds me of:

We took lessons in negotiation from Garry Prior, and at risk of condensing the 20 minute talk that he gave which condensed a three day training course:

  1. Preparation is crucial: always have objectives from the meeting, consider your wish list, think through the trade-offs you’ll accept… and above all consider the other parties’ points of view
  2. Be comfortable arguing: there will come a point where you need to test the assumptions put forwards by all parties, ask questions, clarify, and listen to others
  3. Negotiation must move towards proposal and acceptance: a good format is “if you do that, I will do this”, open realistically and move modestly

Lucie Mclean considered the similarities between a hedge fund manager and a Product Manager. Lucie talked about considering the spread of risk in your product portfolio:

  • Low risk work: optimisation, very specific hypotheses, lots of available data… but not an optimal strategy in and of itself
  • Medium risk work: originating from internal and external signals, “where shall we take this product next?”, no guarantees of success, worth doing an MVP to address the risks
  • High risk work: Huge hypotheses, “what would we do if?”, big changes and big opportunities, watch out for assumptions and “shiny things lust”

Especially with the high risk strategy, think how much you are betting and consider this as your stake… you might lose it, can you afford to?

5.6 – Make your decisions as expected value calculations.
5.6 a. – Raising the probability of being right is valuable no matter what your probability of being right already is.
5.6 b. – Knowing when not to bet is as important as knowing what bets are probably worth making.
5.6 c. – The best choices are the ones that have more pros than cons, not those that don’t have any cons at all.

– from Principles by Ray Dalio

In managing your organisation’s portfolio of risk, you can ask “what is our risk appetite?” As well as “what is our expectation for gains?” I’ve found myself referring to these thoughts recently, as I talk through our product portfolio with colleagues at my organisation.

David Wascha closed out the sessions for the day, with an invitation to Look to the Left. When looking for a new product at Travelex, he and his team asked the following questions of different activities consumers conducted: “how important is this to you?” and “how happy are you with it at the moment?” Traditionally Travelex had concentrated on a series of consumer actions which went:

  1. Get (money)
  2. Go (somewhere)
  3. Spend (money)
  4. Return (and sell spare currency)

When they talked with their customers they found a step 0, a step to the left of the sequence they were looking at:

0. Plan (how much you need)

The goal with the “look left” technique is to extend your engagement with customers. For example at Moonpig, the team are looking left to prompt and remind customers of upcoming occasions they need to send cards for… but also looking right, to close the loop “would you like to send a free thank you card to the sender of this card?” (this answers the perennial card-senders question “did they get my card”, and possibly the more important question “did they get my card and do they think I’m great for sending it?”

Looking back at my notes I got an enormous amount out of MTPEngage Manchester, and I’m so grateful to be living in a city with such an active and engaging product scene.

Call me out for any misunderstandings or odd assumptions in my notes above in the comments, or tell me about other product conferences I must go to.

Dear Reader: Are you in or near Manchester? Do you like coffee? Do you like conversations about product stuff? Check out the Manchester Product Coffee meetup, first date is Wednesday, February 27, 2019 at 9:30 AM in the Spinningfields Benugo. It would be lovely to see you there.

Photo credit for the featured photo at the top: Mind The Product, thank you for the permission to use it.

The power of Experience Visions and the UBAD theory of Gaining Durable Buy-in

My Sunday reading today included a great Jared Spool article on the power of Experience Visions.

You can think of an experience vision as a giant flag on a tall post in the sand, far away on the horizon. The flag is too far way to walk to anytime soon. It will take years. (In the case of the Knowledge Navigator, it was 23 years.)

Yet, because the flag is visible from where we currently are, we can set a directive: March towards the flag. Everyone in our organization can have the same directive. We’re all marching towards the same point of convergence, even if we’re starting someplace different.

– Jared Spool, The Experience Vision: A Self-Fulfilling UX Strategy

Recently Mo Jangda and I wrote “Future Stories of VIP” for each other, as a means of opening up and understanding the personal vision for the future of our work at VIP. We’ve since been posting the stories internally to bring the vision to our wider team for discussion and critique. Reading Jared’s article inspires me to continue writing and refining stories that bring to life the experience of our clients in the future.

Jared finishes with a vision for successful experience visions which is akin to Janice Fraser’s UBAD theory of Gaining Durable Buy-in:

You’ll know your experience vision has taken off when other people start explaining it to you, to make sure you’ve heard it.

It’ll really take off when you hear a senior executive, at some organization-wide meeting, use your story to explain where the organization is heading. They’ll be telling the story (probably getting a few details wrong) to everyone, saying “This is where we need to go.”

What happens next is magical. The organization starts to focus less on what the competition is doing. Decision makers ask What baby steps will it take to get closer to our vision?

– Jared Spool, The Experience Vision: A Self-Fulfilling UX Strategy

I listened to Janice explain her UBAD theory as the third tool for uncovering the truth at Mind the Product London, and luckily for us all this talk was videod and is available for your viewing pleasure:

Uncovering the Truth by Janice Fraser

I love it when the streams collide 💥

I’d love to hear from people who’ve used experience visions in their companies, and how they went about creating and utilising them…

(Photo of Whistler Blackcomb by me)

Thinking about “value”

The more I think about value the slipperier that word gets, but in a recent conversation something crystallised for me, a little crack in the facade of my naivety. I realised that when you’re serving businesses, value is realised differently for the client organisation than it is for the users in the client organisation. (It seems obvious now I write it down, but I’ll plough on regardless.)

At my organisation, VIP, we provide services around WordPress to Enterprise organisations. We think about “our client” at two levels: the client organisation and the users in the client organisation. The “client organisations” are the entities using our service to move their business forward (for whatever value of “forward” that they… ahem… value). The “client users” are the people up and down the client organisation that are trying to do their work harder, better, stronger, faster to create “value” for their organisation, and some of the time they’re using our services as part of their work.

When I think about the potential value in an opportunity, I’m now also considering whether that value is addressed directly to the client organisation, or is afforded to the client users, as well as the frequency or consistency with which value can be provided.

Consider a feature which your clients use only rarely, for example domain mapping. A domain mapping UI needs to be clean, usable, and validate inputs… but clients are unlikely to be mapping domains frequently, so improvements there need to be huge to provide value to a client.

(Of course this is simplified; while a feature may only be used once in the lifetime of a site, we may still need to prioritise it as a vital part of launching a site or unlocking some scaling challenge.)

Alternatively, consider an opportunity to address an issue or improve a workflow for client developers in the course of day to day development, for example syncing data from production environments to test a bug fix. The value client users experience when we improve data sync will multiply over many uses by many individual users across many client organisations. So while editing DNS is important and needs to be done right, the frequency of use of the data sync feature means the potential value provided is greater… so data sync will provide the greater return from the team’s attention.

There’s another class of opportunity, opportunities that open significant options for a client organisation to realise value, either by making something practicable which was previously out of reach, by reducing costs, by consolidating functionality under a single supplier, etc. An example here might be a hosting platform offering a fully integrated global CDN, meaning clients that significantly value page speed and customer experience no longer need to deal with the integration complexity of a third party CDN or pay for it. The right opportunity here can provide much greater value to our clients.

So, crudely, I’m thinking of three buckets, from good to better to best:

  1. Features which are only used once in the course of a client’s engagement with us, though these features may still need to be prioritised, e.g. if they are part of onboarding or some other vital process.
  2. Opportunities to improve workflows or address issues encountered frequently by client users in the course of their work.
  3. Opportunities which allow the client organisation to increase value, protect value, or reduce or avoid costs.

How am I doing? If you’ve got any thoughts on my thoughts, please add them in the comments here.

Photo credit: “Leap” by J F

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).