Make an impact as a new Product Manager in just 30 days
Imagine you’re a new product manager in a new job and you want to make a big impact by using your expertise and experience. Where do you start?
This was the problem I faced when I left a large corporate product management team and joined a SME. And I had exactly the same experience when I joined a startup a couple of years later.
What could I do that would make a difference? As the first and only product management hire, I had a lot of self-imposed pressure to make an impact, so I was keen to find a silver bullet!
Both times, it became apparent that having the right product management process in place would be a great place to start.
3 Tech Team Problems in Any Business
I’ve worked with lots of different tech teams since then, and I’ve seen the same problems again and again:
- Large, unmanageable backlogs in the development team’s tool (Trello, Jira, Pivotal Tracker etc)
- Bottlenecks in story development, preventing development teams from working on chunkier, high-value features
- Difficulty in prioritizing which ideas should be worked on by the product and development teams
The symptoms of these problems are pretty clear to spot — lots of work started, little work finished. Lots of bug fixes and small changes delivered, but the high-value changes seem to fester and never quite get released. Frustration by business stakeholders (and customers) that their feedback isn’t acted upon. A general feeling that the product backlog is a place where ideas go to die.
A few simple changes and a good process can help!
Breathe Life Into Ideas Outside Your Development Backlog
First, get that big list of ideas out of the development tool. They don’t belong there, and just act as a distraction for a team that needs to focus on delivery of high-priority changes. The development toolset is about delivery, not ideation and discovery.
Split backlogs are the best backlogs for a new product manager.
Turn Ideas Into a Manageable Backlog
Second, think about how you can work that big bucket of ideas down to a manageable backlog. Prioritization isn’t just about deciding what the development team should work on, it’s also about working out where to spend product management time. The product manager is expected to spend time in the marketplace, to understand user problems and work out where changes could have a big impact on user satisfaction, adoption, retention and ultimately revenue. How is that possible if you spend all your time writing user stories and specifications?
This is where process comes in. The first step in your process is to identify which ideas are potentially of high value to the business. Of course, you already have a vision for your product and you know your company objectives, so you can use those as a guide for which ideas score highly. If it helps, work with your senior management team to define a set of criteria for your impact score — for example, ideas that fill a competitive gap or are likely to be revenue earning could score highly, whereas a single request from one customer might result in a low score — until you get more requests, anyway.
Once you have that impact score, you can decide which ideas need a development estimate. After all, there’s little point asking for an estimate where the feature isn’t likely to be developed. Straight away, you’ve reduced the burden on your developers — they’ll love you for it! You’ve also reduced that bucketful of ideas down to a more manageable list — good news for everyone.
Hone Your Prioritization Technique
At this point, let’s cast our minds back to an old story that appears in lots of different guises, but is designed to help with prioritization. A philosophy professor stood before his class with some items in front of him. When the class began, wordlessly he picked up an empty Mason jar and filled it with rocks about two inches in diameter. He then asked if the jar was full.
They agreed that it was full.
So the professor then picked up a box of pebbles and poured them into the jar. He shook the jar lightly and watched as the pebbles rolled into the open areas between the rocks. The professor then asked the students again if the jar was full.
They chuckled and agreed that it was indeed full this time.
The professor picked up a box of sand and poured it into the jar. The sand filled the remaining open areas of the jar. If you put sand into the jar first, there is no room for the rocks or the pebbles. Finally, the professor opens a bottle of beer and pours it into the jar, where it soaks into the sand, filling the final gaps.
The story goes on to talk about making the big things in your life (family, friends, health, happiness) a priority before the small stuff like cleaning your house — a philosophy I heartily support! It also points out that after prioritizing everything you need to do, there is always room for beer with a friend!
The same principle applies to prioritizing your workload. If you spend all your time on “sand” tasks — bug fixing, small usability changes — you won’t have enough time to take on the high-value, complex tasks like refactoring an inefficient piece of code, or developing that big new feature you’ve discussed for months. The point here is that it’s important to prioritize the high-value ideas first, even if they represent significant effort.
So let’s regroup! We had a big list of ideas, and by assigning an impact score we’ve reduced it to a list we’d like to get estimated. We now have a list of ideas with both impact and effort, and can start to plan which ones we tackle first — we’re going for the rocks first, and filling in with pebbles and sand where it makes sense. Who knows, at the end, maybe we’ll get that beer when we celebrate the release!
By taking this approach we are focusing our product management time on ideas that make sense, rather than every idea on the list. Hurray, we have more time for customer interviews, competitive research and the myriad other ways of collecting market feedback!
Let’s fast forward a little. We’ve identified the right ideas to be working on, and we’ve worked with UX, customers and business stakeholders to prepare user requirements, user stories, designs, wireframes and anything else we need to hand over to development.
What do we do Next?
It’s highly beneficial to have a formal kick-off meeting, one which sets the scene for the entire team to succeed in building the right thing, and building it right. The meeting should take the form of a 30–60 minute call, and only go ahead where there is representation from product management, UX, development and QA. It’s worth making a particular point of including the developer(s) who will be working on the change, and include a lead developer or architect — whoever is responsible for the technical design.
Start the meeting by reviewing the idea, focusing on the problem to be solved and the expected outcome. Review user stories, specifications, designs etc, and generally ensure that everyone has a shared understanding of WHAT is required, WHY it is required and HOW it is to be built and tested.
At the end of the kick-off meeting, when everyone is happy with the path forward, the user requirements/designs etc can be pushed into the developer’s backlog — likely to be in Jira, Trello, Pivotal Tracker or similar. From this point on the team are focused on delivering a well-defined change, and the chance of rework due to misunderstanding is vastly reduced. Of course, questions will crop up during the development process, but that’s all part and parcel of agile development.
Let’s fast forward again, to the point of release. The development team have worked hard to deliver a new, valuable feature, and everyone has agreed that they’re getting what is expected. Does the process end there? No, of course not! We need to learn about how successful our new feature is. Is it well adopted? Does it solve the problem? That product management process should cover steps for validation and measurement — going back to check on success is an essential part of the product management process, and not to be forgotten.
Originally published at www.prodpad.com on June 20, 2018.
