Why Iteration Beats Innovation When it Comes to Product Process

I used to avoid the concept of ‘process’. I believed that too much process wasted time and held product managers back from building products. I once spent two days in a team workshop discussing a process for new ways of working. Two months later, we scrapped those ways of working for newer ways of working. I spent too much time thinking about process and in meetings discussing process. But then, I joined a company with a process that actually worked, and finally it all made sense. Now, I hardly need to think about the process at all — but not because it’s perfect. Rather, it’s because our entire team has adopted the same process and invests in improving it, allowing it to actually help us.

Product management process is difficult to define. For me, it’s the process by which products are planned for, delivered, and evolved. It varies from business to business and even from team to team. I see product process as the steps needed to complete your day-to-day work — from how you decide on new features to sprint retrospectives. Sometimes, process can distract from what product managers (PMs) want to achieve — when it prevents them from spending as much time as possible focused on the product itself. But, by standardising process, PMs and their teams can maximise efficiency and minimise distractions.

The key to a good product management process isn’t a silver bullet. Good process is achieved by beginning with basic product principles, starting small, and building with repetition and iteration. Considering how much PMs love talking about iteration, it’s surprisingly easy to get this wrong. Like good products, a good process doesn’t happen overnight. The key to a great process is taking something simple, improving it over time, and sticking to it. Much like anything, the more you practice the process, the better you and your team will get. In the long-run, that’s much more effective than spending so much time chasing a magic formula and trying out new trends.

Give process a chance

Introducing a new process is difficult. It usually involves a series of meetings, team training, and lots of complaining. On the other hand, scrapping a process is quite easy. How many times have you seen a new process take more time to implement into a business than it actually lasted, before starting over from scratch? This ultimately can cause ‘process fatigue’, before the team even gets the benefits or understands what works and what doesn’t work.

For example, take backlog refinement. It’s a simple concept: you and your team review tickets in the backlog and refine them until they are ready for development. But more often than not, it’s far from simple. I used to tweak the meeting format each week in the hope of finding a process that would click, or at least be less painful. But the problem wasn’t our process — it was that we changed it constantly. We never had a chance to make it work. I now know that good process takes repetition, and great process takes a lot of repetition and refinement.

Once you have a process that works and everyone follows, it becomes second nature. And PMs won’t have to spend time thinking about how to do their jobs — instead, they can actually do their jobs.

Consistent process helps onboarding

Product teams are almost always busy and hectic, and usually there isn’t much time to dedicate to onboarding. A good first impression of your process is to be able to present a clear, documented onboarding process for PMs. Not only will it help a new PM start adding value faster, it will also make it easier for new PMs to understand what’s expected.

Having a consistent PM process across teams makes PM onboarding itself much easier. It’s difficult enough when joining a new company to learn everyone’s name, new hires should spend time learning about the product, not working out why one team claims to be Lean, and one Agile. Having a consistent process also saves time for onboarders and means you can have PMs across the organisation help with onboarding a new team member.

Onboarding varies business to business, but the goal is to teach PMs what they should be doing after the first week. If the onboarding process consists only of Zoom chats with other PMs and getting set up on Jira, it’s probably too simple. To implement a better process, start with documenting what should happen during onboarding — what topics and training should be covered and who is responsible. By writing down the steps and sharing it, you can ensure that everyone will understand it and be able to refer to it in the future.

Onboarding new PMs without a process is haphazard and costly. It can take weeks or months before a new hire is fully onboarded and in the meantime, the team and product suffers because new hires weren’t given the right background, access to tools, or expectations. By standardising process, a new PM can become more comfortable and efficient in the first few weeks.

Process for cross-team collaboration

Working with many different teams across the organisation can be challenging. But a standard process for collaboration will save time, instead of having to figure out how to work with different teams. Process will also help to set expectations for others in the business when they work with the product team. It can prevent the experience of stakeholders finding that working with one PM differs wildly from another. Or vice-versa — when a PM takes over a new project and finds that the new team has some very different (and difficult) ways of working. A shared process will present a cohesive PM team to the rest of the business and ensure better teamwork and trust.

When Spotify created their famous (infamous?) engineering culture video, they probably weren’t trying to suggest a world of ‘autonomous squads’ where each one demands a different process. Unfortunately, that was the takeaway many viewers had. At the time, I fully embraced the ‘autonomous’ part and somewhat ignored the rest. But the reality is that teams are better off with a process that spans teams, with some variation, rather than operating completely independently.

To enable better collaboration, start with the basics. For example, having teams on the same two-week sprint cycle. A shared timeline enables product and engineering teams to become accustomed to working to the same rhythm together. This will help people outside of the team understand timelines, and it will and lessen the impact of switching teams.

As another example, a defined process for sprint demonstrations can help with collaboration. In previous roles, we tried new demo methods for years without ever getting it ‘right’. We tried smaller demos to remove the pressure of talking in front of large groups. We tried monthly demos, to give PMs more time to prepare, and we tried weekly demos to show off smaller iterations. We tried to reinvent every demo to make it more engaging or impressive, as if there was a perfect format guaranteed to impress stakeholders. But, in reality, any consistent demo schedule is a good place to start. Instead of trying to replicate an Apple product release each week, start small. A quick demo after every sprint, the same day each week, using the same format. It can work wonders.

If you’re currently worried about your product process, just pick one area to focus on, stick to it, and iterate — exactly what you tell your stakeholders. If you don’t know where to start, documenting what you currently do can be super helpful. Not only will it give you a starting point, but it can highlight problem areas. Then, focus on training everyone to follow the same process and creating an environment for getting honest feedback on it. From here, you can track small improvements and make sure you’re allowing enough time for the process to actually work.