7 Things I’ve Learnt in 7 Years of Product
Reflections on product management and ownership from the trenches…
I have now been a ‘product person’ for seven years. Not long in the grand scheme of things, but long enough to work on a variety of products, interact with a multitude of characters and gather some experience along the way.
This is a selection of learnings from my experience so far — it’s by no means exhaustive, but merely edited highlights!
1. People, people, people.
For me, product management has been all about the people — doing my best to help others do their best. That has been through software — delivering products which help them do their jobs, but also through process — enabling users to get their voices heard and enabling developers to work in the most efficient way possible.
This hasn’t always been easy! In fact, as an empathetic friendly helper, in many cases it has been a painful experience. People are strange beasts. All so different. Some easy going, some quite awkward. Some easy to read, others hard to gauge.
However, if I had to choose one thing that has brought me the most satisfaction over the last seven years, I would pick out helping others. I’ve learnt that maintaining strong relationships has made all the difference in my journey through product thus far.
Therefore understanding and appreciating people is my top priority. Understanding users: what are their primary objectives, what are their values? Understanding my team: who are they, how do they work, how can I help them? Understanding stakeholders: how do they think, what are their goals? I don’t, and won’t always get this right — but it’s a far better place to start than blundering straight into the product and ignoring the people.
Without my team or my users I am nothing. Empathy is an important muscle — but it takes exercise to use it well.
If I’ve been able to do my best to help others do their best, then I have succeeded.
2. Don’t be that guy.
Related to people, I’ve observed being a jerk is often less than helpful. Perhaps this is a little too obvious for a reflection such as this, but no one really wants to work with ‘that guy (or gal)’ — the one who ignores what others say, only considers their own opinion and looks after Number 1.
As it happens it is possible to be honest, authentic and transparent — and be a good product person. In fact, it is infinitely preferable! It is ok to admit we don’t have all the answers, or that some aspects are still unclear or that there may just be some holes in the business case. We are in it together after all! We are working together to discover the best solution.
At this point, some of you are no doubt thinking “that’s a bit rich isn’t it? Surely he has some moments when he’s not 100% transparent, honest or authentic?” And you’d be right — part of this transparent honesty is genuinely admitting we don’t always practise what we might preach…but we aspire to do so.
Honesty and transparency breed trust, and trust is a foundation value of a strong team (see Patrick Lencioni, The Five Dysfunctions of a Team).
I learnt early on that it was possible to be honest, admit mistakes and still maintain the respect of the team. The truth is that, far from losing face, I built capital with them. The same was true with users and stakeholders as well as developers. Developers particularly have an uncanny knack of smelling untruths more than anyone else…
Of course this is not a license to play fast and lose. There are only so many times one can ask a team to forgive a careless mistakes, before they start to lose confidence. However working together in a transparent fashion, learning together, succeeding together and failing together makes this less of an issue.
3. Keep the why high by focusing on outcome, not output!
It’s quite apparent there is no ‘right way’ to ‘do’ product management or product ownership, yet some things are clear — it’s more than simply filling out a backlog.
Product is far more than writing stories, although unfortunately in many cases there is where it finds itself. In a Scrum setting, it’s particularly tempting to get fixated with the backlog — especially as the Scrum guide mandates the ‘product owner’ as the role responsible for backlog generation and maintenance.
Yet over the years I’ve been challenged to ascend from a blinkered ‘backlog-centric’ view of product to one of servant-leadership partnering with users and others around the business to identify product success then together work towards it.
What that looks like will vary in each setting, but it involves bringing individuals together around a common goal, unlocking their potential then measuring impact.
It means identifying the product vision (often closely aligned to the organisation’s mission — or at least it should be!) and sharing that as clearly and widely as possible. It’ll involve workshops, research, roadmaps (carefully used), discovery, refinement, measurement, backlogs and much more…
4. Forget the dogma and embrace the principles
I was once told my approach was “very by the book”, like I’d “swallowed the agile literature and would just regurgitate it as required”.
Oh dear.
I’ll never forget that September day, sat in an East London coffee bar. From thence forth I knew something had to change. It was time to forget the dogma and embrace the principles, applying them sympathetically to the situations I found myself in. Thanks Howard!
5. Discover, build, measure, learn and iterate…
I must confess I have learnt this the hard way — by building and shipping, but not measuring and not learning. Okay, yes we did sort of measure it — we assessed the volume of wailing and complaining from the users <sad face>.
I’ve since learnt:
- It requires discipline to ‘build, measure, learn’ as Eric Ries would put it. It means slowing down, taking time to understand the problem, explore possible solutions, choose a possible solution, refine, build then deliver it.
- It needs ‘non-delivery’ effort to do this. It involves inviting developers to set aside time where they are not working on feature output, and focus on the users and their problems.
I appreciate developers are expensive, but then so are designers and product people… Therefore I’d much rather involve them early to ensure we spend their effort on something worthwhile than something we shouldn’t be doing!
- It doesn’t always mean deploying code output to learn. Working with developers, designers and UX experts to produce lo-fi wireframes, prototypes and testing labs is a fine way to learn without cutting a single line of code.
Although greatly misunderstood, the concept of the ‘minimum viable product’ (MVP) is vital to building, measuring and learning. When used as a learning tool, rather than an excuse for bad planning, or poor quality, a series of MVP releases can help us deliver just enough feature to understand how useful it is from our users — and sometimes even deliver some business value as well.
On this basis, perhaps the term ‘minimum viable solution’* might be more appropriate — enabling us to consider each learning step as ‘just enough to help us learn’ rather than fixate on when our product might leave the ‘minimally viable’ phase — in many senses our products will always be minimally viable since we’re only ever doing enough to maximise value returned for our investment.
* My apologies to all those out there who have already coined this term — it’s by no means original to me…
6. Clear communication is not always comfortable communication
When communicating I’ve learnt that clarity is more important than comfort. Tailoring information to an audience takes effort. Not only does the message need to be accurate, it needs to be understood.
I always smile when I think of the Mark Twain quote often associated with some written communication, such as Medium articles:
“I didn’t have time to write a short letter, so I wrote a long one instead.” — Mark Twain
How true it is. This is a lesson I’m still learning — how to be concise and engaging at the same time. Many of you may not have made it this far for that very reason!
Communication also needs to be timely. No good informing users of a change that has already happened.
But it most importantly, communication needs to be two-way. We’ve been given two ears, but only one mouth. Surely (as many have already noted) this means we need to listen twice as much as we speak (or write)? Not always easy — but how open am I to feedback and criticism?
If we are willing to listen to others — that is listen and genuinely engage, not just ‘hear’ — then others will be more willing to listen to us.
7. I am always learning
Lastly, if you’ve worked with me in the past, then you may justifiably believe I hadn’t learnt some of these lessons as this point. You’d probably be right — so please accept my sincere apologies.
One thing is sure, I’m learning there is always more to learn — be that from users, colleagues, my network or others out there in the trenches sharing what they’ve learnt — therefore I’ll be learning until I die. I hope so anyway — you have my permission to hold me to account…
Does this resonate with you? What have I missed? What do you appreciate? Let me know your feedback below — I look forward to hearing from you!
