Differentiating great product features from the merely good doesn’t require invention of new frameworks, lucky guesses, or divine intervention. It does require standardization and consistent application of a method for identifying the value of any given thing, so that you can confidently say “Yes!” to the great ideas, while deferring less valuable ideas and eliminating others which may be distractions.
3Protocols prefers the RICE Framework for prioritizing product deliverables because it is simple, repeatable, scalable, and objective.
Your product has bugs, a backlog of feature enhancement requests, technical debt to pay off, you had a great shower thought this morning. Then, an RFP from a potential enterprise customer has just landed on your desk – did it identify product gaps? You bet it did.
Let’s learn about a method for filtering all of this input so that you can confidently say “Yes!” to the great ideas, while deferring less valuable ideas and eliminating others which may be distractions.
Choosing the right method for determining what does and does not go onto your product roadmap doesn’t require invention of new methods of thinking. But that thinking does need to be consistent, objective, and repeatable.
The RICE Framework requires us to rank the following characteristics of each potential product deliverable: Reach, Impact, Confidence, and Effort. Once you’ve assessed each of these factors, you apply a formula to produce a quantifiable RICE Score.
RICE offers a simple and repeatable method prioritzing potential product deliverables. In order to achieve this though, the team must agree on how each category is scored.
The formula for RICE is:
RICE Score = (Reach x Impact x Confidence) / Effort
Consider the following example for a product that is undergoing a redesign, wants to expand to enterprise customers, but requires existing customers to remain happy, so that they’ll refer new customers.
| Deliverable | Reach | Impact | Confidence | Effort | RICE Score |
|---|---|---|---|---|---|
| Redesign Login Screen | 1500 | 1x | 90% | 3 | 450 |
| Fix Dashboard Filtering Bug | 800 | 2x | 80% | 2 | 640 |
| Add New Enterprise Feature | 1,000 | 2x | 70% | 10 | 140 |
| Add the Whimsical Shower Thought | 1500 | 0.25x | 50% | 5 | 67.5 |
Evaluating each of the RICE Scores helps us objectively prioritize stability of existing features that customers use (that’s a strong “Yes!”). After that, we’ll finish the redesign work that we’ve started. Only after that will we add new features that an enterprise customer added that we think may be beneficial to other customers. Our Whimsical Shower Thought that we think might impact every one of our customers, turns out to be a distraction.
When prioritization of your potential product deliverables is based on objective analysis rather than personal intuition, you can confidently say “No” to poor ideas or distractions while more clearly communicating to customers and stakeholders the value in what you’ve built and what you’re going to build.
]]>Relaunching and extending the scope of the 3Protocols site to include a blog required thoughtful consideration of scope, requirements, and available technologies.
For every software developer maintains a website and blog, I’m sure 90% of them have also made reference to the old saying:
The cobbler always wears the worst shoes
… Or maybe it was:
The cobbler’s children have no shoes
Whatever of these you prefer, the point is that many software developers don’t find the time to build their own website or blog because their efforts are reserved for solving problems for their clients or users. Yet, sharing my perspective about pragmatic product development is important to me. So, I proceded, but not without some requirements.
There’s a rich ecosystem of static site generators (SSGs)that are built on top of Ruby, Python, Javascript, Go, and myriad other languages. The core value proposition of SSGs is that they require no server-side processing (pages load very fast), are very secure (no server-side code to be exploited), and are very easy to deploy. As a developer who specializes in Ruby, my choice of SSG was Jekyll.
Jekyll lets me write the site and post content in Markdown, create a deployable site with a single command, and then upload the contents of the site to an AWS S3 bucket – which was infrastructure I was already using to host the previous version of the site. From there, I use CloudFront to cache and distribute those static files.