01 Aug 2024, by Calum Shepherd
I set out to answer the question ‘What are the qualities of a good product strategy?’.
We all aim to create strategies that are well understood and for colleagues to feel comfortable socialising them, but just how do we go about doing that?
It felt like strategies should have some consistent qualities, and if we get those right then we could free up our time to worry about the ‘what’ of the strategy.
So, I spent some time doing some research.
I’m going to cover what a strategy is, why one is important, what to avoid, and what to aim for.
I hope it helps you as much as it’s helped me!
What is a strategy?
“a detailed plan for achieving success in situations such as war, politics, business, industry, or sport, or the skill of planning for such situations” - Cambridge Dictionary
The key thing for me here was the phrase ‘detailed plan’. I have always tried to make them as clear as possible, and clear often means a sufficient level of detail - so it sounds like I was on the right track.
Why is strategy so important?
Your product strategy is what drives alignment and coordination across your company. It ensures everyone is pulling in the same direction at the same point in time. It’s about creating focus.
Imagine shipping a series of new features for a specific segment over the month and your marketing campaigns all being ready to go, customer success talking about them with confidence, support being ready to answer questions, and sales pitching to these new segments.
This really resonated too, and definitely felt like something I had been aiming for.
What makes a bad strategy
Sometimes it is easier to start with what something isn’t.
- It isn’t fluffy. Some people might explain that strategies ‘aren’t supposed to be actionable’. They’ll paint a vague picture for you, leaving you unable to take action. That isn’t ideal. If it isn’t actionable, it isn’t a meaningful strategy
- It isn’t financial metrics. Simply telling your teams to increase revenue shouldn’t really be considered a strategy either; it’s a method to measure success. If you target X segment with Y value to achieve Z revenue, then that’s a much better place to be
- It isn’t how your teams collaborate either. Explaining how your teams will work together isn’t a strategy; that’s probably more a topology. Team topologies define the purpose and relationship of teams. They are important, no doubt, but I’d steer clear calling them a strategy
If you are into team topologies, then you can read a great post on team topologies by Martin Fowler. It’s a fantastic read :)
What makes a good strategy?
The best write up I found wasn’t from a product management source (surprisingly). It’s Good Strategy, Bad Strategy by Richard Rumelt. You can pick it up on Amazon for cheap as chips.
And, this excellent Marty Cagan piece on product strategy.
So, what makes a good strategy?
- It identifies a series of problems or opportunities
- Written in the order you’ll tackle them
- Each has a diagnosis breaking things down a little
- Each has a series of actions for the team(s) to enact
Additionally, a good strategy should also:
- Be in plain English
- Have a ‘curator’, or ‘owner’
- Be updated when new insights come to light
- Be re-communicated when changed
- Be an iterative document
- Be explainable by everyone across the company
- Move you towards your product vision
I’m planning to stick to this from now on, and hopefully it’ll allow me to continue refining things for the better in the coming months!
17 Jul 2024, by Calum Shepherd
I spotted these adages on the web a few days back.
These all resonated with me instantly, and not just because one of them is from my favourite movie of all time!
- Murphy’s Law
- Gilbert’s Law
- Kidlin’s Law
- Wilson’s Law
- Falkland’s Law
Read on to find out more about each and how to apply them.
Murphy’s law
“Murphy’s law is an adage that is typically stated as: “Anything that can go wrong will go wrong.” In some formulations, it is extended to “Anything that can go wrong will go wrong, and at the worst possible time””
Sounds gloomy.
I remember this one from Interstellar, and it’s stuck with me ever since.
- If you have worked in the software industry for some time, you know everything isn’t plain sailing. There’s so much within your control, but a whole lot more is dependent upon others playing their part (e.g., usable designs, reliable code, etc.).
- Conduct sufficient planning to consider major edge cases or potential problems. Discuss designs and implementations with engineering, considering the customer perspective to help mitigate issues.
- When things do go wrong, tackle them with positive energy and engage the right people. You can view it as a frustrating failure or an opportunity to learn—positivity and proactivity are important.
Gilbert’s Law
“The biggest problem with any task or job is that no one tells you what and how to do it.”
Also the name of my father in-law.
Gilbert’s Law is why it’s crucial to be incredibly organised as a Product Manager.
- Don’t dive into new work without a plan. Take five minutes to think through what’s required to get from problem to solution. You might already have some product development principles to follow, and you can adjust these as necessary.
Planning can take five minutes or a bit longer—know your plan and communicate it to the relevant individuals.
Kidlin’s Law
“If you write the problem down clearly, then the matter is half solved”
I don’t know where this one comes from, but I love it.
- If you have read How to Create Tech Products Customers Love, you know the importance of properly assessing opportunities. The first thing you are asked to tackle for this basic write-up is a clear, succinct problem statement. It’s actually one of the hardest things you will ever write when tackling a new problem.
- Don’t let people push you into an instantaneous solution. You’ll end up iterating a solution further and further away from the actual problem, which will remain unknown.
Play back your understanding of the problem to your colleagues and customers. Is this exactly what we wish to solve? Is it specific enough?
Once you have done the above, you can confidently begin to iterate on solutions to solve it. You’ll discover a few things along the way, and that’s OK.
Wilson’s Law
“Wealth is not an immediate goal but a byproduct of prioritising knowledge and intelligence”
Now, you might think this one is a little silly. The more you get paid, the wealthier you become. But there are two aspects to consider here.
- You become more employable the more experienced you become in the right areas. Take on new challenges, push boundaries, and new avenues for success will open up to you. When they do, people will be more willing to pay you suitably.
- Wealth doesn’t just come in the form of money. I have taken various roles over the years that were more about the product and people than anything else. Also, life is short—family is important. Don’t sacrifice an endless amount of time at their expense.
Falkland’s Law
“Think about the things that are absolutely necessary”
This is huge.
- When you have narrowed in on a specific problem, it’s easy to be drawn into a world of other problems that may or may not be related. You’ve got to be focused. If you can solve a broader range of problems through a bigger solution, fine, but that’s not what you set out to do—be clear about that. Often these are problems for another day, not today.
And there we have it.
There we have it. Five adages and how to apply each of these as a Product Manager!
17 Feb 2022, by Calum Shepherd
I wanted share some thoughts on how our product management team have approached the product communities most divisive topic - product roadmaps.
What was the aim?
Improve our current product roadmap so everyone across the business can understand what problems we intend to solve for users, in what order, and have some indication of when a customer might see these changes
What were the areas for improvement?
We made some significant changes to our roadmap format during the last year, and most of these were made in one go. Many of these were positive. But, both formats saw feedback that was, at times, conflicting.
We began at the beginning. We ran a survey to understand what people liked and disliked about the current format.
What did we learn? People appeared to find the current roadmap unclear. We hadn’t struck the balance around what we were working on, vs. when people might expect to see these things, and consistency in the level of information.
How did we coordinate things?
It was assumed that changing too much in one go would be confusing for everyone involved. Sometimes when you fix three problems, you end up causing three other problems - so we wanted to work from what we had.
We followed a little plan to make sure we could do that.
- Surveyed everyone across the business to understand likes / dislikes
- Session with senior management on their needs
- Made and had approved recommended changes
- Consulted and collaborated with product managers on the changes
- Updated the company, and produced guidance
How does our product roadmap look today?
Some of the main changes include;
- Organised using now / next / later so people know when things will begin
- Updated titles to be clear on the value to customers
- Aligned to objectives
- Added consistent descriptions
- Statuses provided (new idea, candidate, discovery, delivery, shipped etc)
- Indicative release window (eg. Q4, or March 2022) on the card
- Consistent level of granularity between items
- Linked to opportunity assessments (an assessment of the value of the idea)
And, here is a visual of the format;
What about public product roadmaps?
We’re keeping our product roadmap internal only, as all this information isn’t useful for our customers.
However, we have a draft of an alternative product roadmap for our community to consume. It’s going to be used to gather feedback around things which we need more information about, helping to ensure we deliver the right thing for customers. So, for that reason the format differs.
- Organised using now available / in progress / considering (split into thinking about doing, and need more feedback on)
- Reduced information on each card, with now available / in progress including a sketch of the idea
Here is a visual of the format;
What next?
It’s going to be all about listening now and actioning feedback. We’re also looking at rolling out the public product roadmap to our community in the near term - which is pretty exciting!
C
11 Jan 2021, by Calum Shepherd
I tend to write up notes from books, or just highlight them as I go. I read when I can, but make no conscious effort to read regularly. It’s worked for me in the past, but when things get busy the learning suffers.
So, this year I’m going to have a commitment to read a book a month every month. It doesn’t seem like much, but it should get me into a good cadence again to help me think differently and continue to learn new things.
What’s on the list?
-
Michael J Fox - No Time Like the Future. I’ve read his other books and his optimism has always shown through. However, after a couple of setbacks, how does he view things now? Emotive, and always an excellent read.
-
Mapping Experiences: A Complete Guide to Creating Value through Journeys, Blueprints, and Diagrams. I’ll be honest, talking at cross purposes when it comes to mapping techniques seems like a regular thing for teams. Using an experience map to understand how customers interact with your business is different from a story map, for example. I’m hoping this will tighten up my game, and help me use the right tools at the right time.
-
Agile Product Management with Scrum. Roman Pichler’s other book Stratgise was a fantastic read around some basic product management concepts to create alignment and direction. This focuses on the more granular practical application in a scrum environment. Worthwhile knowledge top up I hope.
-
User Story Mapping: Discover the Whole Story, Build the Right Product. Jeff Patton is well known in the agile community, and I’ve never read this (embarrassingly). So, I’m going to read it. After going remote story maps fell out of favour for me, and that’s a shame. It’s time to kick off using them again.
-
Forever Employable How to Stop Looking for Work and Let Your Next Job Find You. I’ve been meaning to read this for ages. Theres been a few occasions where I have felt my a-game is dipping, and I’m wondering if I am losing my edge. I’m hopeful reading this will help me regain some confidence, allow me to rethink a few things, and keep me sharp in the months ahead.
-
I also just finished reading What Do We Do Now?: A product manager’s guide to strategy in the time of crisis. Randy Silver is an amazing person to follow on Twitter, and has a knack for making things super easy to understand. Short, sweet, and essential read for times of turmoil. I recommend this one for only 4 pound!
And, that’s so far.
I’ll dig out some more in the coming months once I begin working through these. Ideas always welcome, ideally in the software architecture space!
10 Apr 2018, by Calum Shepherd
Joining a service when the team have been through discovery, alpha and beta phases together can be challenging.
It’s a team that’ll have bonded through some tough times, and come together to solve problems with their users.
There are no fires to put out, so what do you do in the first 30 days?
Listen
I took the first two weeks to listen as much as possible, with as many people as possible.
It’s amazing what you can learn when you care about what the other person has to say.
Ask questions, and listen - product, people, process, technology and finance are good places to start.
Immerse yourself.
Understand
Listening helps you understand, which in turn helps you make sense of things.
It’ll be an iterative process in the first few weeks. You’ll think you’ve got it, then you will realise you don’t - and that is OK.
You’ll want to know about the organisation, stakeholders, service proposition, user needs and so much more - it’s a lot to make sense of and understand in such a short space of time.
Beginning to understand things is bringing all this together into a coherent whole.
Don’t rush.
Nudge
It’s time to begin to make small interventions, where you feel those interventions will be valuable. You can work with individuals where there is something specific, helping move things in the right direction - nudging things in the right direction ;)
Collaborate with the team as a whole to tackle bigger things - such as new problems to solve or questions to answer.