We’ve all been there. You are working on a product, your team and clients get excited about it and start sharing an early build with friends and investors. Before you know it, a number of new features and ideas about what the product should or could do are on the table. These ideas are often informal opinions of people we trust but, as they are not the result of user-testing, agile teams often lack a structure to filter, refine and incorporate them into the product.
As a result, many of these points are either ignored, or vilified as one of the Product Manager’s worst nightmare: ‘feature creep’. This is a missed opportunity, and one that could easily be resolved by looking at the Workflow and working out a way to incorporate the ‘new’ without derailing the product development process. And here is how.
Riding the Brainwave
As product managers, we love to optimise the way we build products. In fact, happiness often takes the form of an idea that not only improves workflow for your team, but also benefits the Product Owner and ultimately (not to mention most importantly), the user.
When you follow a user-centric approach to building a product, you are creating something from your customers’ and business’ perspective. The features of the product emerge from validated user needs (or user stories) that make their way to your backlog. Once there, items get prioritised and added into a sprint, and you will iteratively build your product from there. So far, so good.
However, this workflow has a flaw that I think a lot of Product Managers who have embraced Agile and Lean will have experienced. Especially us PM’s that come from a user-centric philosophy or from a design background. Specifically, it can allow very little room for new ideas and assumptions to influence the development. Because we are moving so quickly and everything is already prioritised, to fit something NEW in gives you a bit of a headache.
But what if you get a brainwave for an improvement or a slight pivot to the product’s direction? Following a user-centric approach, these items in your mind are not validated user needs, so how can they make their way into your Agile workflow?
In my experience, the solution is quite simple – you need to allow room for completely fresh ideas and assumptions within your sprint cycle. How? It’s pretty simple. You basically add in an element of testing to validate these ideas within the sprint.
Incorporating a “Gitflow”
To develop our approach at Hive we borrowed concepts from an engineering concept called Gitflow. Originally created by Vincent Driessen at nvie, this is a process that facilitates collaboration, parallel development and allows for the handing off of priorities.
We found it helpful because it nicely illustrates the process of handing off priorities along a timeline and merging outcomes. It also didn’t hurt that the team already understood the ideas behind it.
Two buckets of items:
To add new ideas into your agile workflow, you need to have two buckets of items. One bucket contains your ideas and assumptions,The other bucket works the same as you would with any product backlog: you estimate the effort of the items, you prioritise based on the importance for the user and the business, and you start from the top of the pile.
The next step is to take an item or items from your assumptions bucket and create tests around it to run in your current or upcoming sprint.
Real World Example from Kindeo
The easiest way to explain this is with an example. We are currently working with Kindeo, a product that helps bring families together by sharing memories. In the middle of the sprint, we had a brainwave – if our secondary users (that is not the users that would generate the stories, but those who would view them) invited their parents or grandparents to share their stories, then the product would become a more personal and inviting experience.
As a team we discussed how we could validate this new assumption. We decide that the best test would be to add “invite someone” functionality to the landing page, track its usage, and get feedback on the experience. After a week, we had some results and concluded that this was a feature to develop in in the next sprint.
In short, it is all about “hacking” together a test for the your assumption as quickly as possible, validate it as a genuine user need, and then working on it (or not!) in a future sprint.
Using the Gitflow to manage two workflows
As I mentioned earlier, I believe that incorporating this into your agile workflow is easiest done in a Gitflow model, treating the idea validation process as a complimentary workflow. Your new Gitflow will have a new Branch to consider, but ultimately works on the same principles. What we have created is a second, complimentary workflow within the same sprint, as explained in the image below. As a Product Manager, you can treat the new workflow the same as any agile development sprint – take items from a backlog, estimate, execute and learn.
Once you have established a good workflow and your product owner has bought into this, you has a Product Manager (perhaps collaborating with a project manager) now have to manage two separate workflows within your sprint. Obviously, you won’t have the same kind of user stories you’re probably familiar with, but there are ways of sizing these pieces of work and smoothly incorporating them in the team’s planning.
In this process, it is important to timebox the testing and agree on a metric of success for it, for example “We will agree this idea or assumption is a validated need when X=Y”. Agreeing those kinds of success metrics are naturally a challenge, but a valuable one to wrestle with, essential if you want to be able to effectively test new ideas. This will obviously also have an impact on your product development cycle, but it will also frame learning and idea validation in a way that is accessible to everyone in the team.
The Benefits
As a Product Manager, incorporating and managing new ideas within your workflow in an efficient way is very powerful. Here are some of the clear benefits:
1.Everyone understands what it takes
As the whole team has been involved in the testing of the idea and understands both the benefits and the complexity of the new feature, it will be easier for them to estimate the effort of building it.
2.You avoid unnecessary features
As the Product Owner has been involved both in the idea process and the testing, it’s easy to discuss and assess the importance of each new feature. What’s more, you will have not only your own experience to fall back on, but real user data to help in the discussions as to whether a feature should be built or not. It is not about guessing the value of random new ideas, but about listening to what the users are saying when presented with new ideas.
3. The user “rules”
This is an inclusive approach where everyone is part of the the design and the development process – the team, product owner, and even investors. All ideas have the opportunity to be tested with your customers, and the users are the final judges as to whether this is something they want or not.
To Summarise
Overall, this is an approach that gives products the best chance to succeed, introducing the flexibility needed to learn and validate ideas as they arise without derailing your sprint.
Hypothesize, validate, build, iterate and repeat for better products! If you have any comments or other ideas in how to include new ideas in your workflow I would love to hear them.
Comments 2