How do we know if the products we build will be widely accepted and adopted – that what we’re building will be a success?
I believe this is a question that we may never be able to answer with 100% confidence. But, what we can do is mitigate risk through continuous improvement and sound decision-making. During my tenure at CAKE, we’ve done some pretty cool things to address this question. In this three part blog series, I’ll share three of our biggest success stories with you.
Why the Roadmap is Important
After giving our development process a boost by implementing some of the major aspects of the Agile Methodology, we turned our focus to our development roadmap. Like our agile/scrum project backlog, the roadmap is basically a bigger wish list of everything CAKE as an organization would like to build into our product. As part of the product envisioning process, the roadmap basically answers the question, how do we identify and ultimately rank the items we need to build?
As Product Managers, one of our core responsibilities is prioritization. It is up to us to know which features are important to which stakeholders, including customers, developers, and the business, and ultimately, recommend the order in which features are built. It is also imperative to the unity of the dev team and the sanity of the exec team that we be completely transparent on how the roadmap is prioritized and communicated.
Doing the math
For a solution to our need for transparency and proper, objective prioritization, we felt a mathematical formula would work best. There might still be disagreements about what should get built next, but with a precise mathematical formula setting the priority, even if it is based on subjective numbers, there is always a precise and consistent manner in which projects are prioritized.
Essentially, our formula can be decomposed in its simplest form to Benefits over Cost. It gives us a quantifiable, unbiased way of ranking features and cuts out the unending circular discussions about what’s most important to build next.
We call our formula the Platform Value Score or PVS! With PVS, the sum of each priority factor, or the benefit, is divided by the level of development effort, or the cost. This gives us a “PVS” number that we can then use to determine the priority of the feature that needs to be built.
Here is exactly how it works. We assign a number on a scale of 0 to 3 for each of the following values according to the level of priority, 0 being of no or little importance and 3 being of extreme importance:
Retention (R): Based on client requests for a particular feature or based on future proofing the platform. This value also measures the amount of demand coming from internal stakeholders to improve process.
Opportunity (O): Based on projected revenue generated from current clients and prospects.
Innovation (I): Based on technical innovation associated to our product in the competing market.
Client/Stakeholder Commitment (C): Based on agreed upon client deadline or contractual agreements.
Development Effort (LOE): Based on either total story point value or development architect rating (which is based on estimated story point value).
When To Calculate the PVS According To The Formula:
(R+O+I+C)/(LOE) = (PVS)
Each feature is listed in the project roadmap in the order of its PVS number, largest to smallest, or most important to least important. We then use this roadmap in determining what our development teams work on during their next sprint. The roadmap is continually managed and updated, giving us a real-time view into what feature needs to be built next.
Stay Tuned!
Now that we have agile and a process in place to actually score and rank features that need to be built, how do we ensure each pillar (each with its own task force) is getting the focus and attention it needs? Stay tuned – I still have one more product development process success story to share with you – how we use the concept of budgeting to better allocate our development resources. Keep an eye out for it in the coming weeks.
