3 Ways to Introduce an Agile Product Development Process
As ProdPad’s Chief Commercial Officer, I’ve worked with lots of different product managers. I regularly hear about the challenges they face with their agile product development processes. The relationship with development is key, and managing the product backlog to ensure development can deliver is hugely important.
It often feels like product development vs product management, and I see the same problems occurring over and over again.
- A large, unmanageable product backlog in the product development tool (Trello, Jira, Azure DevOps etc)
- Bottlenecks in story development, preventing development teams from working on chunkier, high-value features
- Difficulty in prioritizing which ideas should be worked on next
The symptoms of these problems are pretty clear to spot. Lots of work started, little work finished. Lots of bug fixes and small changes, but high-value changes fester and never quite get released. Business stakeholders (and customers) become frustrated that their feedback isn’t acted upon. There’s a general feeling that the product backlog is a place where ideas go to die.
If you’re hoping to work in a more agile way, you’ll be glad to know that a few simple changes and a good process can help!
Breathe Life Into Ideas Outside Your Product Development Backlog
First, get that big list of ideas out of your product development tools. They don’t belong there. Half-baked ideas clogging up the development backlog act as a distraction, and prevents focus on delivery of high-priority changes. Development is about delivery, not ideation and discovery.
Give your development team the space they need to work on their product development workflow. Not only will they deliver more big ticket items but they will be happier and more focused.
Turn Ideas Into a Manageable Product Backlog
Secondly, it’s time to tackle that big old bucket of ideas and get it down to a manageable backlog. Prioritization isn’t just about deciding what the product development team should work on, it’s also about discovery. Product managers need to spend time doing market research and to understand user problems. They need to work out where changes could have a big impact on user satisfaction, adoption, retention and ultimately revenue. That isn’t possible if you spend all your time writing low priority user stories and specifications!
This is where the agile methodology comes in. The first step in your process is to identify which ideas are potentially of high value to the business. You already have a vision for your product and you know your company objectives. You can use those as a guide for which ideas score highly.
Work with your senior management team to define a set of criteria for your impact score. Ideas that fill a competitive gap or are likely to be revenue earning could score highly. 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 get to the development team. Straight away, you’ve reduced the burden on your developers – they’ll love you for it!
As we consider prioritization, let’s cast our minds back to an old story that is a great analogy for how to attack this thorny problem.
Hone Your Prioritization Technique
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 across. He then asked if the jar was full.
They agreed that it was full.
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.
The class chuckled and agreed that it was 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. Putting the sand in first wouldn’t leave room for rocks or the pebbles. Finally, the professor opens a bottle of beer and pours it into the jar, where it soaks into the sand and fills the final gaps.
Applying the Theory in Practice
The same principle applies to prioritizing your workload. Spending all your time on “sand” tasks means you won’t have enough time to take on the complex high-value things that make a big difference. Challenges like refactoring an inefficient piece of code, or developing that big new feature you’ve discussed for months are put on the back burner and often left behind. 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.
By taking this approach we are focusing our product management time on ideas that make sense, rather than every idea on the list. We now have more time for customer interviews, competitive research and the myriad other ways of collecting market feedback, which is the core of the product manager’s role.
What do we do Next?
Let’s fast forward a little. We’ve identified the right ideas to work 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 product development.
We need to have a formal kick-off meeting with the product development team, 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.
It’s a good idea to 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, push the user requirements/designs etc into the development backlog. This is likely to be in Jira, Trello, Azure DevOps or something similar. From this point on the team can focus on delivering a well-defined change, and the chance of rework due to misunderstanding is vastly reduced. Questions will crop up during the development process, but that’s all part and parcel of agile development.
Released Doesn’t Mean We’re Done
Let’s fast forward again, to the point of release. The team have worked hard to deliver a new feature, and everyone is happy that it meets the requirements. Does the process end there?
No, of course not! We need to learn about how successful our new feature is out in the wild. We need to check whether the feature is well adopted, and whether it solves the problem. That product management process should cover steps for validation and measurement – going back to measure success is an essential part of the product management process, and not to be forgotten.