This post is the 3rd in a series on Product Management for the AppExchange. The fourth installment: Closing the Loop: Collecting Customer Feedback for AppExchange Products can be found here.
The Power of Roadmaps
Getting to the MVP version of a product is important. If you have done your core responsibility as a Product Manager, you have a problem target, a product vision and a design that hits components of that strategy. In order to get to market, fast, you chose the most obvious hard hitting features to serve your market problem, your Minimum. Good thing you are building on Force.com and the platform has done of all the heavy lifting! Getting a MVP live on the AppExchange is fundamentally faster than ground up product development. When’s the last time you deployed a database schema on Force.com? Didn’t think so.
Beyond that MVP release, the world gets quite a bit less clear. Strategy and design work always creates more potential solution ideas than a MVP can hold and the next most important task is creating a product roadmap. You need a roadmap that is prioritized well for the future.
Product roadmaps are perhaps the most important thing you do as a product manager post-MVP deployment. Good roadmaps communicate the future in a compelling way to key stakeholders. The best AppExchange product roadmaps:
-
Communicate Multiple Timeframes of Development with Suitable Resolutions
-
Features for the next version
-
Modules for the next FY
-
Communicate Product Strategy and Vision
-
Clearly gain alignment across the business landscape and connect the roadmap to the strategic vision
- Are Mutable!
-
Roadmaps are by definition living documents. They are a snapshot in time and must be kept current, feeding new information back in as new inputs, causing re-prioritization
-
Are Quantitatively Prioritized
-
Data! Data! Data! Marry quantitative research with qualitative analysis for evidence-based initiatives. Collect data on results and feed those results back into future versions
-
Are NOT Backlogs
-
Product roadmaps should provide guidance for potential features and the strategic reason for them but should not reach user story level detail. The scrum team (product owner) uses the roadmap during user story grooming as an implementation guide
-
Line up with Salesforce.com Product and Platform Roadmap
-
As ISV partners, we gain access to feature pilot and platform roadmap information before the general public (safe harbor!). This allows inclusion of new SFDC technologies in packages soon after GA release
It’s worth noting that roadmaps are not necessarily product focused. Technology, architecture, and marketing roadmaps can all be useful depending on the initiative’s needs. They likely have interdependencies as well. Marketing initiatives driving feature development and architecture expansions, for example, help communicate larger strategic vision.
Leverage Modern Roadmapping Tools
Product Roadmaps are living documents, focused on high-level product strategy and goals. They need flexibility to allow for re-adjustment when new information becomes available. The best mechanism for this is integration to the product and project management tools. Fortunately we live in an excellent time for this effort. There are some amazing tools that have been created with varying cost and complexity. Each has differing integration features and/or onboard product management capabilities. A non-prioritized list of some good ones include:
Prioritizing Features
Prioritization is hard. Knowing what to build next to satisfy the complex needs of one or many targeted personas while market forces are shifting underfoot is a daunting task. Not only is this a challenge for one person to handle, but rarely does only one person apply priorities to a product build. Persons who develop the strategy are not the same as those who write user stories or set the backlog prioritization. The roadmap is the mechanism with which strategy is communicated across an organization and the product manager’s task is to un-jumble all of the competing strategic initiatives into a clear path forward for the product. The information stored in the roadmap is not just about what features or modules to build and in what order, it should communicate the rubric that is used to decide that priority. Once the entire development landscape understands WHY the priority is set the way it is, there will be no confusion left and organizational alignment can be reasonably achieved. Also, a properly communicated prioritization framework can help defend against a rogue stakeholder or a single large client’s desired feature. If it doesn’t fit in larger strategy, it doesn’t get built!
Develop a Framework
Defining a framework for prioritization is not a response to a lack of information but a lens to apply when you have far too many ideas. This will happen! With all of the modern data collection and analysis tools in the marketplace today, it is very easy to generate a list of ideas whose scope grows beyond any one person’s ability to consider holistically. Even worse, it can be easy to see the inclusion of any or all of the ideas in the product but no possible capacity of the development team to build them all in a reasonable timeframe and investment budget. Whenever possible, utilize a multivariate scoring system and publish that on the roadmap so that all parties can see directly why a given component or feature has priority.
Mental Models
The use of mental models in decision making processes are not by themselves a prioritization framework, although many are applied in frameworks. Mental models are extremely useful when deciding on what or what not to build. Gabriel Weinberg, founder of Duck Duck Go, recently published a list of the models he uses and it is the most complete list I have ever seen. Leveraging known decision models can help you avoid common logical traps when processing feature priority.
Prioritization Methods & Techniques
The following list of techniques is not intended to be the full set of possibilities but a path forward to consider. In addition, many of these tactics are not necessarily digital product nor AppExchange product specific and can be used for a wide range of decision making needs.
Customer Feedback
A great source of potential feature ideas, and therefore priority weight, is feedback from your existing customer base. This source can be extremely insightful with regards to how your current version is being used and will very quickly show you if you have not evaluated personas well or if you have missed one or more. Beware of blindly building what you hear from this group. They represent current state and are very valuable for identifying incomplete user flows and impactful missing features. These features should be evaluated with the lens of the future product roadmap. Building all of these ideas is the source of feature bloat/genericization.
Competitive Analysis
Competitive analysis should always be performed when building any product, and much of that need is pre-MVP build to understand the market landscape. During roadmap prioritization, evaluating your competitors can be extremely useful for a couple reasons. First, to determine must-have features. In the same way that you wouldn’t use a Learning Management System that was poor at delivering learning content, evaluating deal-breaker feature misses can prevent post-conversion churn. The second reason might seem strange to you, but you should evaluate the closest competitive landscape to identify what not to build. One of the quickest ways to lose product traction is to become a “me too” product. Download your competitors’ packages from the AppExchange, try to use them, and repeat this effort at a minimum once per quarter. Find where the space between products is and follow that trajectory. If your problem solution fits that space, you have a winner!
Analytical Prioritization
Utilizing evidence based prioritization is critical in today’s world of product management. It is difficult to the point of impossible to convince wide ranges of stakeholders to buy into a common direction without strong evidence. Beyond that need, however, is the fact that a single person’s brain cannot hold all of the competing ideas, their complex costs and impacts simultaneously. (Even if there were someone with this capability, there aren’t enough to go around and that person should probably be solving cancer…)
You’ve got to be able to defend and justify your priorities. I find two things help with this: First is to use objective data to help set priorities. A little data resolves a lot of arguments. Second is to involve your key stakeholders early and often so they feel they’re involved in the planning, that it is THEIR plan as well.
Value/Effort Model
Value/Effort is a simple but effective way to group potential features for prioritization. It relies on:
-
Evaluating a feature’s cost or effort
-
Evaluating a feature’s impact or potential user’s delight
-
Plot all the feature’s cost vs impact on an XY scatterplot
Weighted Scoring
When evaluating cost and effort, being even more scientific can help – especially with lots of potential features. A great way to apply more solid numbers is to break value and cost into categories and assign them a value between 1 and 5. Assign each category a weight, multiply the score*weight, then sum the value weights and the cost weights for each feature to plot on the x/y chart.
-
Example Effort Categories
-
Implementation Effort
-
Operational Cost
-
Risk
-
Example Value Categories
-
Reduced Customer Churn
-
Strategic Value
-
Increased Revenue
Placing the crossbars helps you decide which things should be worked first. Beware! Too many low value/low effort items leads to feature bloat and bored users but Your Mileage May Vary (YMMV). You may have success, you may not.
Kano
Kano feature scoring is a popular tool, created in the 80s by Noriaki Kano, and assigns scores to 5 categories of evaluation; touching on required functionality up through excitement features with mechanisms to weed out conflicting preferences. This tool requires a large amount of customer research surveying but has shown promise understanding complex groups of customer needs, and how delivering features changes a user’s base need over time. Jared Spool over at UIE explains the details far better than I can! Give it a shot, you’ll find it useful.
Case Study: Pandora Buy a Feature – How Pandora Went to 70 million Users with 40 Engineers
With Buy a Feature prioritization techniques, you take a group of potential features, assign a complexity to them in $ and hand out a stack of money to a prioritization team. In 2011, Pandora utilized this technique to great effect, force multiplying a 40 engineer team to gain 70 million users.
From Tom Conrad, the CTO of Pandora:
“To make this easy for everyone to grok, Pandora decided to express scope in terms of dollar amounts. Basically, a feature that takes one engineer one month to complete is worth $5. If it takes them two months, it’s $10, $15 for three months. So if you’re thinking about dedicating an engineer to one project for the whole 90 days, that’s $15. If you’re going to put two engineers on it, that’s $30 and so forth,” he explains. “With this in mind, we put dollar values on each of the idea slides we made.”
The key point of this effort, for me, is the focus that is achieved every quarter:
“A miracle occurs — you end up with a manageable number of tasks that can be executed with the resources you have, and you have buy-in from leadership in only a few hours.”
The Art of Saying No
In closing, I want to leave you with a nugget to consider. As you prioritize your product’s features, remember that one of the most important things in delivering a strong product is staying focused. If a feature, theme or initiative doesn’t fit with the product vision, the general business strategy or the market fit, SAY NO!
