Running the Product Council for Rally ALM has been an interesting learning experience. Any time you take a group of VPs and directors from a rapidly growing business, put them together in one room, and ask them what your product should do, you're setting yourself up for a challenging and possibly contentious conversation. Each person has a different set of responsibilities and motivations.
At Rally, Evan (VP of Services) wants to make sure we're building the features that our coaches can use to help customers be successful with Agile. Don (Sales) wants to make sure we have a competitive product that solves the problems that prospects care about. Marc (Support)would like us to build features that solve problems existing customers struggle with. Dan (Partners) wants to support partners who are building integrated solutions. Mark (Integrations) needs API capabilities to support his team.
It's critical to get input from each of these different groups, but often there is no correlation between their requests. Marc's existing users might all be clamoring for the ability to re-arrange a particular screen, but Don's prospective users are so thrilled to have the screen at all that they don't notice it could be improved.
Without good facilitation, it's easy for a group like this to get mired in conflict and disagreement. I've found that if I don't spend enough time preparing for the meeting, it's really easy to have conflict erupt during the meeting and derail the process.
Over many releases with this group, I've learned six things that seem to make a big difference for this group.
more:
1. Don't go too small or too techncial.
If you ask a VP-level stakeholder to choose between a big strategic feature and a normal-priority defect, what's going to come first? The feature. It's easy to assume this means you shouldn't waste time on small defects or usability improvements. This is a dangerous assumption that takes you down the path of buggy software to the valley of angry customers.
When you mix backlog items of different sizes, the small items will tend to sink to the bottom, like the vinegar and herbs in a homemade salad dressing. The only way to get small items to stay suspended in a salad dressing is to add an emulsifier, like mustard or guar gum.
Fortunately, Product Owners can act as a good emulsifier for your backlog.
We've found 3 categories of items that should definitely be handled outside of the product council process: defects, small usability enhancements, and technical debt. The first two should be managed in their own backlogs and blended just-in-time into the Product Backlog by the product owners, each iteration. Technical debt should be managed by the technical team and blended in during each iteration.
2. Abstract solutions don't sell themselves.
If a customer tells one of our account reps they want to "track individual availability across iterations", it's easy for us to write a set of stories, vote on them, and implement them. By default, a new product council group that's run purely democratically will do lots of these stories, but that's only because clearly defined features that the customer asks for by name are easy to prioritize.
But there's often more leverage in building features that solve more than one problem at a time. If I can build a new feature, like "contextual highlighting", it might solve many different customer problems at the same time.
Unfortunately, nobody is asking for "contextual highlighting". Customers are sending very concrete requests to the support team, saying they want us to "make the parent story name visible on the backlog page". Prospects are asking sales reps generic questions on how they can "track status on larger initiatives within the release". As a product owner, it's your job to design the abstract solution that hits all of these problems at once.
If you show up at a Product Council meeting and add "Contextual Highlighting" to the list, none of your stakeholders i's going to vote for it, except the one guy who was an engineer 10 years ago and still misses writing code. For the rest, even if they get it after your 5 minute explanation, they're not going to remember 2 weeks later what the value.
You need to pre-sell this kind of feature, 1-on-1, with each member of your product council. This takes time. You also need a name that incorporates the benefits so it's easy for everyone to remember why we want this. "Contextual Highlighting for Large, Complex Projects" reminds stakeholders why the feature is a good idea.
3. Build lightweight business cases
If mob mentality is ruling your product council, it's really easy for not-so-good ideas to float to the top. Got a stakeholder who's demanding that you translate your product to French so he can sell to the Québécois this month? Before you launch into a project like this, someone needs to figure out exactly how big the market is and whether it's the right market to go after right now. I require my stakeholders to produce a high-level business case (less than a page long) before we'll begin researching an epic like this. We need to know at least:
- How many customers are requesting this feature?
- How many customers does this feature benefit?
- How many users does it benefit?
- Would this feature have a negative impact on any of our customers or users?
- What is the cost of not building this feature?
Since there's always an infinite pile of good ideas, this helps ensure we only spend time on the ones that have clear benefit.
4. Not every feature is ready for development next release
Sometimes the Product Council gets excited about building a new feature, and tries to rush it into development before we've had a chance to think through the risks. The Agile process reduces the risk associated with this, in that a bad idea almost always gets stopped after an iteration of development. But for me, each development hour is precious, and I can't afford to waste any development time on something that isn't definitely going to be good for our customers. One way to think about the Product Council process is that it's designed to optimize a continuous flow of stories to the development team.
To make sure half-baked ideas don't hit the development team, we have started to stage our epics through 4 backlogs:
"Ideas" are things we've talked about, but that have never been evaluated in depth for size or feasibility.
"Exploring" items are currently being researched by Product Owners and others, but are not quite ready to be developed.
"Ready For Development" includes items that the Product Owners feel are understood well enough to be pulled into Release Planning.
"Work In Progress" items are pieces that we've started but not finished yet. In the past, we've sometimes moved on from a feature before we get to some of the lower-priority parts. By keeping this list visible, we're reminded that we want to finish the things that we've started before moving on.
5. Value all ideas
Every week, my stakeholders run into customer situations that could be greatly improved through the addition of a new feature. It's easy for them to get passionate about this feature, even if we've already discussed the idea and decided that the big-picture business case isn't there. If you allow endless rehashing of every issue over and over, the product council loses its focus, but if you don't provide a context for the issue to be raised, your stakeholder will find a way to bring it up anyway.
The "Ideas" backlog is the receptacle for these items, but this only works if it's visible during the meeting. If the item is already in the "ideas" backlog, ask the stakeholder whether it's time to revisit the business case for the item.
Again, there's an infinite number of great ideas and a finite amount of development resources. The vast majority of great ideas are not the right ones to implement now. The process needs to block the so-so ideas and only let the excellent ones through.
But as market needs shift, last quarter's so-so idea can become this quarter's excellent idea. Your process needs to allow re-examining these old ideas from time to time in case they've become more timely.
6. Think Roadmap, not Release
This has been a tricky thing for our group. In the past, we oriented the Product Council toward preparing for releases. But since we work on an 8-week release cycle, and we have limited capacity, many stakeholders have to "sit out" releases while we build features for other constituents. Focusing the product council directly on a release makes the meeting more contentious.
So for 2009, we're restructuring our meetings more towards managing a continuous flow of work through our 4 backlogs, and talk more about prioritization at the roadmap level.
Posts
