All about ... product process

When it comes to the product process, we are effectively talking about the whole process from idea generation through to customer usage, and everything in between, which might sound like a tall order for a product manager to take on.

However, changing the whole process is the task of the whole business, and it's the PMs role to guide the business with a few well placed processes and steps so that they take themselves on the journey to transition.

For me the core areas in which a PM can support the overall process are:

• Managing ideas

• Reviewing ideas

• Preparing work

• Delivering work

Managing ideas

One of the misconceptions about Product Managers is that they are responsible for making the product ‘better,’ but I’d argue that this goal is the responsibility of everyone with any vested interest in the product. Where the Product Manager really earns their money is in sorting through all these ‘make things better’ ideas and working out which ones will make it ‘much, much better’ and which won’t.

The Product Manager is not the source of ideas when it comes to improving a product.

They’ll have some, because they are close to the coalface, know the product as well as anyone, and are constantly looking for signs that something needs improvement. By virtue of constantly facing up to the data, and the customers, it makes the Product Manager the recipient of many signals of product improvements. However, anyone is in a position to make a product suggestion.

Customers most certainly know what they want to do, how they’d like to do it quicker, more accurately, more regularly … Sales folks also have a direct line to product improvements, as their regular contact with potential customers means they can see what barriers to sales you might have and how these might be overcome. Your customer success team (or whatever you call the first line team who handles incoming queries) have the insight into what is causing pain to existing customers, your finance team might be aware of the challenges of getting paid, or more importantly not getting paid, your technical team get alerts that tell you where customers are experiencing issues, the list goes on.

You don’t know who’s going to give you ‘The Idea,’ which means you need to keep a hold of ‘All the Ideas,’ which means you’ll end up with a metaphorical warehouse full of ideas. When you look at it in these terms, the challenge for a Product Manager goes from being how do we know what’s going to make things better to how can we look for the idea in this giant warehouse of ideas to find the ones that are going to deliver the most value? For that you need a method of assessing and categorizing the ideas, so you can mine and find the nuggets.

These ideas need to be stored outside of your backlog and categorised so you can find them easily, and you can read more about how to create and manage your ideas warehouse here.

Reviewing ideas

Another product management misconception is that the product manager chooses what work the teams are going to work on next, and although there is some truth to it, the PM does not do this in a vacuum.

The only way for a PM to select the right next piece of work, is to understand what the business's priority is at that point in time, which means tapping into the strategy and performance of the business at regular intervals.

If the PM doesn't know that sales have trailed off, how will they know to prioritize features that support the sales cycle? If the PM doesn't know that by the end of the year that the product is to be launched in a new market, then how will they know to prioritize language features?

A skill a product manager needs to learn is to understand who we need to pay attention to in order to steer the ship. There's no point listening to the head of marketing if the head of sales is driving the strategy. There's no benefit in knowing what the CTO thinks should be next if they've not spoken to any customers in twelve months.

It's important to find the right people and the right forums for getting the information that then informs the way the backlog takes shape. That means, putting in regular meetings that fit with how the work gets scheduled, such as strategy meetings every quarter and bi-weekly catchups on current priorities, with the focus on letting others know that you are giving them the opportunity to shape the future work.

Preparing work

Most product managers will tell you that they have too many different things to think about and not enough time to think about them in, which means you need to get people onboard to support you with the thinking.

You've already spoken to the commercial sides of the business when getting the ideas and the priorities, and now the development team get to have more of a say.

If you've done your job up to this point, and got the outline of a feature, with the measures for success, clear deliverable goals, and structured acceptance criteria, once you've walked the team through the work then you should be free to let them run with the solution, which in turn allows you time to work on future priorities.

Therefore you need to find regular time to walk your team through the upcoming work so that they can get their heads around what's coming up. It also gives them the chance to ask questions that you might not have considered, which you can then take onboard. In agile development these are the backlog refinement sessions, but this approach isn't just fixed to agile and teams running sprints. Regular reviews of upcoming work is key to quality delivery and teams pulling in the same direction.

If you've given the framework in which the team can utilise their skills then they'll be more than willing to find the most effective solution to your users problem.

Delivering work

Once you've set the team off and running towards the goal, then the deliver is on the whole down to them, but as a PM you need to make sure that the team know what to do if they have any questions or thoughts.

You want them to know when to come to you and when to just solve the problem, but we do come back to how clearly you've written the work request. It should be clear for the team that if the question doesn't alter the outcomes you want then they have some freedom to solve the problem how they see fit, however, if the desired outcomes are going to change then they need to verify this with the PM.

After all, it's the PM that was closest to the business when making the decisions on what work was going to be done. It was the PM that spoke to the end users about what they needed and why. And it was the PM who wrote up the requirement.

This is one of the reasons why life as a remote product manager is a little more challenging, as the opportunities for the team to pop over to your desk are reduced, but it's not impossible to deal with. The important thing is that everyone is clear.

Conclusion

If we can get the ideas formed by the team in an effective way, manage them efficiently, prioritise them as per the business needs, brief the teams so that they can work on them without you, then you've got a slick process that will support your product delivery without causing you to be firefighting and jumping from one thing to the next. The process just works, even if you're on holiday.

Further information

https://medium.com/hackernoon/observations-on-product-management-3abc7e00148e Dan Hill's (AirBnB) observations on product management

Managing a warehouse of ideas by Robert Drury on Medium