How to Live by Product Principles, and Improve Your Process
Most people reading this will know the product development principles they want to live by. Outcome focussed, guided by data, experimental, a focus on learning…the list goes on.
But knowing the principles is only the first step though. The second step — living by them — is more difficult than it first seems.
How many times have you launched a new product or feature and realised you could have validated it far sooner, and far easier? Or how many times have you spent a couple of months in ‘delivery’ mode, with only a vague link to what you’re trying to learn, or the metric you’re trying to move?
Whether or not these examples chime with you, from my experience very few teams feel they’re really working by the principles they want to. It’s a little like teenage sex — everyone’s talking about it, no-one’s doing it. (Or if they are, it’s not as great as they say it is…!).
Emerging From the Day to Day
Before we get into the ‘how’, there’s a simple concept that helps. The product principles we all strive for aren’t single actions you take. Instead, they’re a pattern or way of doing things that appears over time. Or put another way, they are emergent, and only appear as the result of multiple, consistent actions.
Take this example. You’re not ‘guided by data’ if you look at a metrics dashboard once. Instead, reviewing data — to guide strategy, give signals of potential problems, or signals for success — needs to happen on a consistent basis, and be embedded in how you operate.
Applying the Principle
To go from this theory to action, first recognise that are a set of different artefacts around which our day to day operates.
These include tools that you look at to organise and arrange your work (e.g. Trello, Jira), reports that inform on progress and allow you to make decisions, and meetings where all of this comes together.
So if your your tools, meetings and reports embody the principles you want to work to, you should start embodying these principles.
Doing this can be very simple, and very quick to do. Here’s some examples from teams I’ve recently worked with:
- Action: Added a column to our Trello (a tool) titled “released and monitoring success”
Why: To make 100% sure we learn from what we’ve released and reflect on whether it was the right thing to do or not. - Action: Prefaced monthly marketing reports with ‘current learning objectives’.
Why: To make sure we don’t get lost in the delivery of a ‘plan’, and forget what we’re trying to validate. - Action: Setting a mid-quarter goals review to update on progress.
Why: To make sure we act on new data — should it come in — and pivot/persevere with each initiative accordingly.
Easy as One, Two, Three
In each of these cases, we followed three simple steps:
- Agreed the principles we wanted to follow (sometimes this was implicit, other times we did a session to agree them)
- Reviewed our meetings, tools and reports to see whether they embodied these principles, and what was missing
- Where relevant, tweak a tool, report, or meeting accordingly
Pretty simple, easy to do, but also easy to miss.
Bad Tools, Bad Habits
If the right tools or meetings help you work by the right principles, it stands to reason that the reverse is also true. Put simply, poorly chosen or configured tools can get you into bad habits.
For example, I’ve met many teams who worry that they’re just ‘building things’, instead of consistently learning how to improve their products. Where do these teams spend their time? Nearly entirely on Jira. And what’s Jira for (at least in its basic configuration)? The delivery of sprints, not learning or moving a metric.
Now I’m not saying you should ditch Jira entirely (although of course many PMs I know would love to!). But if you spend the vast majority of your time reviewing and managing Jira, you’re probably missing things like:
- A clear product strategy, including metrics that matter,
- Details of initiatives or bets that you think will achieve the strategy/move the metrics in question,
- A backlog of these bets, and a set of discovery actions to validate/invalidate them,
- Periodic reviews of progress against the strategy or metrics…
..and so on.
So if you feel you’re in a ‘build trap’, follow the steps above. Set the principles, review your key artefacts, and gradually transform your tools, reports and meetings to match.
Simple Fix, Huge Impact
I don’t know whether you’ve clocked it, but we’re really talking about here is process improvement. But there’s a very good reason I haven’t mentioned the ‘p’ word until now. In the past, whenever it’s been discussed in the teams I’ve lead or been a part of, things get difficult. Sometimes it’s seen as a luxury. Sometimes is seen as too big to tackle. Other times it’s given to someone to go away, design, present back, then no doubt sit in a drawer until it’s discussed again in a few months time.
But it matters. It really matters. The core principles of product development are there for a reason. If applied well, they work.
And after all, It’s the sum of multiple day to day actions and decisions that will dictate the success of the product you work on, and business you work in. Put another way, product success is emergent too, so you need to pay attention to what it emerges from.
On board? I hope so. And if you are, book in a meeting now to discuss this with your team. I’ll bet there’s a number small changes you can make which will appear subtle at first, but have long-lasting impact.
Just avoid the ‘p’ word, if you can.
