3 Ways to Introduce an Agile Product Development Process

Product managers often discuss their challenges with establishing properly Agile product development processes. The relationship between management and development is key, as is prioritizing your product backlog to ensure the dev team can deliver.

It can sometimes feel like it’s product development vs. product management, and there are a few common recurring problems, such as:

• A large, unmanageable product backlog in your 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.
• Making lots of bug fixes and small changes, but leaving high-value changes to fester unreleased.
• Business stakeholders and customers becoming frustrated that nothing is done about their feedback.

These can all be signs that there’s a general feeling that your product backlog is a place where ideas go to die.

Luckily, If you’re hoping to work in a more Agile way, all you need is a few simple changes and a good set of processes.

1. Resurrect ideas by getting them out of your product development backlog

First things 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 prevent focus on the delivery of high-impact changes. Development is about delivery, not ideation and discovery.

Give your development team the space they need to work on their development workflow. Not only will they deliver more big-ticket items but they will be happier and more focused.

That means splitting your backlog into a broader product backlog of ideas and a more focused and specific development backlog of tasks. You’ll probably find that using tools like ProdPad to organize your ideas and attach them to solutions will give you a more effective way of managing your teams’ workloads. It makes introducing Agile product development processes much easier!

2. Rank your ideas by impact and effort to turn them into a manageable backlog

Prioritization isn’t just about deciding what the product development team should work on, it’s also about discovery. That means it’s time to tackle that big old idea dumpster and turn it into a manageable product backlog, so you can get on with your real job.

Product managers need to spend their time doing market research, learning about user problems, and working out which changes could have a big impact on user satisfaction, adoption, retention, and ultimately revenue… to name just a few of the things that you’ve probably got sat on your to-do list right now.

None of that is possible if you’re spending all your time writing low-priority user stories and specs, and that’s where Agile methodology comes in. The first step in your newly implemented Agile product development process is to identify which ideas are potentially of high value to the business.

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 on the same topic, anyway.

You surely already have a vision for your product and you know your company objectives. You can also use these as a guide for which ideas score highly.

Once you have that impact score for each of your ideas, you can decide which ones need a development estimate. After all, there’s little point in asking for an estimate when the feature isn’t likely to get to the development team.

Straight away, you’ve already reduced the burden on your developers – they’ll probably love you for it!

3. Learn how to prioritize for Agile product development

There’s a story that people often use when talking about prioritization: a professor stands in front of his class with an empty jar. He fills it with rocks and asks the class if it’s full, to which they all say yes.

The professor then pours small pebbles into the jar and asks again if it’s full. The class again says that it is. He pours in the sand, and again the class thinks the jar is full. He finishes off by pouring water in, soaking the sand, and filling in the final gaps. Cue a room full of blown minds.

In case it’s not obvious, the jar is your workload, and the things you pour into it are the various tasks that you need to complete. Spending all your time on “sand” tasks means you won’t have enough time to tackle the complex, high-value ideas that could really make a big difference.

Complex challenges like refactoring an inefficient piece of code or developing that big new feature you’ve discussed for months end up being put on the back burner, and can often end up left behind entirely. It’s important to prioritize the high-value ideas first, even if they represent significant effort.

That doesn’t mean you can ignore the smaller ideas, of course, especially if they’re high impact and low effort. You might even find that starting by working on a smaller idea can give you the momentum to take on larger challenges. But in Agile product development, the lion’s share of your focus should be on the rocks, not the sand.

What do we do Now?

Ok, let’s regroup! We had a big list of ideas, and by assigning them each an impact score we’ve reduced it to a list we’d like to get estimated. Now we have a list of ideas with both impact and effort established, and we can start to plan which ones we’ll need to 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 on every idea on the list.

We now have more time for customer interviews, competitive research, and 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. We’ve worked with UX, our customers, and our business stakeholders to prepare user requirements, user stories, designs, wireframes, and anything else we need to hand over to product development.

Next, we need to have a formal kick-off meeting with the product development team. This will lay the groundwork for the entire team to successfully build the right thing, and to build it right.

The meeting should take about 30-60 minutes, and should only go ahead where there is representation from product management, UX, development, and QA. It’s worth making a particular point of including the developers who will be working on the change, and including a lead developer or architect – whoever is responsible for the technical design, in other words.

It’s a good idea to start the meeting by reviewing the ideas you’re looking at, focusing on the problem to be solved and the expected outcome. Go through the user stories, specifications, designs, and so on, and work towards everyone having 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 that the path forward will be using Agile product development processes, 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 product development.

What do we do Later?

Let’s fast forward again, this time to the point of release. The team has worked hard to deliver a new feature, and everyone is happy that it meets the requirements. Does the process end there?

What do you think? If you read the heading, you’ve probably already worked out the answer. That’s right, releasing a product or feature is just the end of the beginning.

We need to learn about how successful our new feature is out in the wild. We need to check whether the feature is being adopted well and solves the problem. And we need to ensure the feature is working as expected now it’s in the hands of our users.

Your product management process should cover steps for validation and measurement. Going back to measure success is an essential part of the process, and not to be forgotten.

If the Agile product development approach resonates with you, now’s the time to try a different kind of product management tool that supports this process. Start a free trial today, and see how ProdPad can revolutionize how you deal with your backlog.