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.
29 Oct 2017, by Calum Shepherd
I popped along to a conference for product people in Birmingham last week. Canvas Conference was brimming with great stories from people working in the product space. It included speakers from companies such as Thriva, Microsoft Research, Starling Bank and Monzo this year.
However, I’m not sure I was prepared for one of the presentations - nor were quite a few others whom attended.
Emotionally, it was a bit of a rollercoaster.
Haiyan Zhang is an Innovation Director at Microsoft Research. Haiyan works with people to identify where technology could improve or enrich their daily lives, where medical conditions put them at a disadvantage.
Haiyan talked about quite a few things, including a new platform for participants, and the need for making solutions financially viable further down the line.
Parkinsons is a disease affecting 10 million people worldwide, and leads to a loss of motor control.
There is no cure.
I know first hand the effects that this disease has on a human being. It’s been close to me since I was a young boy. It has the ability to strip back all the things you cherish.
So, it was getting into Project Emma that was the most striking for me. It’s ambition was to help Emma, a women diagnosed with early on-set Parkinsons, write and draw again - giving her back a little of what had been taken away.
Haiyan and her team spent vital time sitting with Emma to better understand the importance drawing plays in her life, and more widely how Parkinsons has affected her daily life. Haiyan and her team worked day and night for months to better understand the problem and explore a solution to help Emma.
Remarkable, right?
It’s helped remind me that we all have a role to play. I guess most of us shape solutions for the majority of people, however people and their needs are heterogeneous - with all the complexity that brings.
We have a responsibility to those who have different levels of ability, or who need support to see the benefits that the things we build bring to people.
It’s why research, analytics and how we build things are so important to do right by our users - whoever they are.
C