When I’ve pulled some data into Google Sheets I often want a way to quickly chart the count of something, maybe it’s support tickets and I want to chart the incidence of particular tags or count tickets for each customer. In this situation I want a nice neat chart showing from ordered data.Continue reading Count and sort in Google Sheets using QUERY()
All models are wrong, but some are useful– George Box
I’ve been using a quote in roadmap presentations as a nod to the inevitability of change:
“No plan of operations extends with any certainty beyond the first contact with the main hostile force.”– Helmuth von Moltke the Elder
Reading the Wikipedia page for Helmuth, I now learn he was the creator of a new method of directing armies in the field. Rather than directing all movements in detail, he relied on setting objectives and allowing subordinates freedom to execute within the general framework of the mission. This seems very close to the metrics driven, management by objectives that we see many modern product teams using. Dare I mention OKRs?
Here’s another nice quote, via Marty Cagan’s chapter on Product Objectives in his excellent book “Inspired“:
“Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.”– General George Patton
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:
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)
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:
- 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.
- Opportunities to improve workflows or address issues encountered frequently by client users in the course of their work.
- 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
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.
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 😃
- 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
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
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.
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".