Traffic Congestion: Too many options

Even if your startup has an existing product to emulate, like if you were building Uber for Mars, there are too many possible features and not enough time or resources. This is true for a bootstrapped solo effort and a Series A venture-backed startup with millions in the bank.

For some startups, they have a product team that owns the roadmap. They likely have a tool that they use, maybe Trello or Asana, and they may have weekly or biweekly planning meetings where they plan and prioritize.

But most startups don’t have product teams, they have founders and maybe a few extra engineers or operations people.

So what do those startups do?

Who knows?

Probably Trello or Asana.

Or like us, they use a good ol’ spreadsheet.

We have a simple one that lists the feature, the customer(s) who have requested and/or are eager to try it out, a tentative release version and data, and a link to a tab in the sheet that provides more details.

Here is our current roadmap, with some customer info removed:

The FormKiQ Roadmap: About as barebones as you can get outside of a cocktail napkin. If you want one for your very own, you can download a template here: Simple Product Roadmap

A Straight and Narrow Street: is this oversimplified for real life?

But listing features may not be enough. There are other parts of roadmapping that aren’t included in this sheet, and the ones that cause the most trouble for startups is the value and estimated effort of each feature on the roadmap.

How do we know which of the items on our list are most important? How do we know which of these items will take so freaking long to do, that we will fall behind our other commitments and feel like maybe the whole startup is a mistake?

Enter RICE prioritization.

Or should it?

Too Many Lanes: The RICE is nice, but is it too much?

RICE stands for Reach, Impact, Confidence, and Effort. It was created and first popularized by the team at Intercom. For more information you can read this article from a former Intercom PM, Sean McBride.

The score is a formula based on those aspects:

(Reach x Impact x Confidence) / Effort

This gives you a numeric score you can use to rank each item on your roadmap.

Reach: How many of your users (existing or expected) would be affected by this roadmap item?

Intercom uses actual numbers of users instead of an arbitrary scale, but for startups that have few or no users, a percentile of potential users (like 0 to 100) may be more practical than using a small sample size of existing.

Impact: How significant would this feature be for those customers?

The Intercom scale is: Massive = 3x, High = 2x, Medium = 1x, Low = 0.5x, Minimal = 0.25x.

You could try a simpler scale like 1 to 10, but this would slightly change the weight of impact on the overall scoring formula, as 0.25x is a twelfth of 3x, whereas 1 is a tenth of 10, so the difference between the most and least impact is slightly smaller.

(A 1-12 scale would match the Intercom impact scale, but it may feel very arbitrary when choosing between a 7/12 and an 8/12.)

Confidence: How confident are you in those numbers for reach and impact? Are these existing customers? Do you know that they would use this feature? What percentage of confidence would you give?

The Intercom scale is: High = 100%, Medium = 80%, Low = 50%.

And the hardest one:

Effort: How much time (probably estimated in ideal engineer days, weeks, or months) do you think it will take to complete this feature?

Of course, estimating effort is a difficult task. Do you know how many days of work a feature will take to complete?

Will you (and can you) include the time to test the feature, create documentation or training, if needed?

When possible, the people who will do the work should be involved in the estimates of effort.

If you are planning for work a contractor or yet-to-be-hired engineer is expected to do, will you actually be guessing anywhere close to the reality? Is that possible if you don’t know the skill and experience level of the person who will do the work?

We expect that our effort will not be correct, but hope that it will be plus or minus 50%. So if we say it’ll take five days, it shouldn’t be done sooner than two and a half, and shouldn’t take longer than seven and a half. If we can’t be at least that sure of the effort, we probably need to do more research and consider breaking the feature into a few chunks that are easier to estimate.

But even if you can come up with great guesses for the R, I, C, and E, do you actually need that? Is RICE right for your roadmap?

That depends on your team, your product, your customer base, and your timeline and runway.

Crash Test Dummies: How we prioritize

When we’re working on our product, we don’t bother with RICE prioritization. We just don’t need that methodology right now, or at least that’s the conclusion we’ve reached.

Here are some questions we’ve asked ourselves while roadmapping, along with our answers:

1. Question: Do we have trouble deciding priority for items?

   Answer: Not really. We don’t have a huge backlog of items, and it’s pretty clear right now which ones are more immediate items to consider, versus future nice-to-haves.

2. Question: Do we have a good way of estimating effort?

   Answer: Yes. We can make solid estimates within a plus/minus 50%, and that’s probably close enough.

3. Question: Is RICE scoring too complicated for us?

   Answer: No, actually. We have a sheet we can use: Simple Product RICE

4. Question: Do we enable customer or prospect input on our roadmap, and how important is that input?

   Answer: Yes we do, and that input matters. Now that we are beyond a minimum viable product, and we are adding features based on the additional value they create, we use both customer and prospect suggestions and feedback to help prioritize.

For us, our small but growing number of customers are asking for specific features; this isn’t just from paying customers, but also from users of our free, open core offering, as well as prospective customers as well. Of course, our paying customers get priority, whether for bug fixes or feature requests, and we even have one-on-one sessions with customers to discuss our current roadmap.

One day, we will likely have enough requests that we will need to score them, and when that happens, we could either look at a simpler prioritization method, like the MoSCow Method and it’s “Must Have”, “Should Have”, etc., or start with RICE.

The Shape Up Method

Mid-article Footnote: Another interesting methodology is the Shape Up Method, a product development methodology introduced by Basecamp that emphasizes fixed periods of time, called "cycles," during which a development team focuses on defining, building, and shipping a set of planned features. The goal is to prioritize work based on value and maintain a sustainable development pace.

Road Reclamation: What about stripping some features off of the roadmap?

There are three main ways of removing features from the roadmap:

1. Build the thing
2. Delete the thing completely (unlikely)
3. Offload the thing

So in most cases, the best way to reduce the backlog without deleting is offloading the feature to another product or provider.

As a company offering deployable document management features, we’re in the business of helping organizations offload items on their roadmap. But most software companies are in that same business, too, whether they are providing a product like a SaaS or team augmentation / offshoring services.

When we look at our own roadmap, we also look at how we might offload some of it. We have a team of engineers, but there are always more opportunities than there are team members to pursue them.

So when we look at features like computer vision, a rich text content editor, eSignatures, or a mobile client, we start looking at what might already be available to mark that feature complete.

Our first principle of sustainable product engineering is that we never write new code for functionality that is readily available another way.

Here are the steps we follow to offload features:

1. 
   1. Investigate Cloud Services First

   If Amazon Web Services has an available service, we usually explore that option first. In some cases, we will end up providing both the AWS service and an open source alternative, to enable a lower-cost option for users of FormKiQ Core. We usually start with the AWS offering, to better understand the technology and use cases, with the open source alternative coming after that.

   A good example is optical character recognition (OCR); from almost the first release of FormKiQ, we offered Amazon Textract via our paid offerings, FormKiQ Pro and Enterprise. But we’d always expected to offer a lower-cost version for customers who may not need the extra functionality and accuracy of Textract, and with the support of our friends and partners at CANARIE, we were able to spend the time and effort to add Tesseract as an open source alternative for OCR, available in all versions of FormKiQ.

   For a future roadmap example, when we investigate computer vision offerings, we’ll likely start with Amazon Rekognition, and then we can investigate other options.

2. 
   2. Check Open Source

   There is almost always an open source alternative to writing something ourselves. Almost always, because in some areas like AI and computer vision, the alternatives may not have been created yet. But despite the large number of open source projects, we often choose not to use most open source options for our features, especially if they involve backend services.

   This is because most open source projects that go beyond the client side have tightly coupled application architecture tiers, whether between the presentation and application layers or between the application and data layers. Usually the data layer is PostgreSQL, which is easy to build a project with, but disqualifies most projects from being usable in our architecture, which emphasizes scalability and flexibility by removing the need for server instances whenever possible. And at this time, we don’t consider Aurora Serverless V2 to be a good fit for that architecture. Here’s a good explanation of why not.

   We don’t expect most open source projects to dump PostgreSQL, just as we don’t provide an easy way of swapping out our NoSQL datastore (DynamoDB) with a relational database.

   We are currently working on ways to propose and prove out a separate Document Layer when working with documents. We hope that in the near future, more applications will begin to de-couple document persistence from structured data persistence, resulting in more open source projects that we can adopt as part of our stack.

   Until then, we may look at open source as inspiration, or we may even find front-end projects for items like rich-text editing, where we can take the JSON outputs and integrate that with our architecture.

3. 
   3. Consider Commercial Applications

   If we have no AWS services or workable open source solutions, we look at commercial products that might provide any feature for us that isn’t a critical, core piece of functionality.

   eSignature is a great example of this. It’s not part of our core mission, but it’s something that is often required as an add-on. While we have investigated some open source options, we haven’t found one that works for us right now, so we have a few commercial integrations that are available instead.

   We started with DocuSign, since that was the alternative most often mentioned, but we now are ready to offer SignWell due to its ease-of-integration and right-sized pricing for our customers.

   It’s possible that one day we will see a need to provide our own built-in eSignature functionality, knowing that it will be a much more barebones offering than the commercial alternatives; if that happens, we may luck out and find a suitable open source solution that has cropped up in time.

4. 
   4. Professional Services for the Periphery

   We haven’t done this yet, but that doesn’t mean we won’t. There are some things that are not part of our main functionality, that have nothing to do with our competitive advantage or our expertise. In those situations, engaging an outside partner to build those things can make the most sense.

   The most likely candidate for this right now is a mobile client for document management. Our current document web console is not well-suited for mobile use; while we could spend a few weeks testing it out and ensuring the widescreen web version also displays well on smartphones, we don’t think the end result would ever be considered a great mobile experience. For that, we’d likely want to have a new client designed for mobile.

   In that case, we’d likely start building it with something like Flutter, to enable iOS and Android, as well as web and desktop apps, although it would likely be from a customer request, so there may be other considerations that would change the technology choice.

   But no matter the platform chosen, it’s unlikely that we would build that product internally, since we are not experts in mobile development, despite having experience in iOS, Android, and desktop applications.

   And since there is no cloud service, open source project, or commercial product that functions as a document management client for the FormKiQ Document API, engaging with a partner to build this feature makes the most sense.

   But obviously, we have features that we built ourselves, because those are the core features that we are the best-suited to create. If we expect that we would spend more time describing what should be built to a partner than building it ourselves, there’s not as much value in that partnership.

5. 
   5. Build It Ourselves

   This is the final option on the list, but we often find ourselves reaching this point. Obviously some features need to come from us, like orchestration and integration between services and products, while others need to be written because we couldn’t find another alternative that worked for us.

   Why don’t we want to build everything? It’s not always about the development time, though building some less-critical pieces would likely be a distraction from the most important functionality of our product, and features that require specialized knowledge may not be a great fit for our internal team, especially when those features have a high impact on security, compliance, efficiency, and overall risk.

   It’s often the maintenance that creates problems. If we spend a year building features and we launch them, and customers begin using those features, we now need to maintain those features for an indefinite period, most likely for several years or longer. Even if maintenance of a feature, which often includes required security updates, takes only 10% of the time it took to build that feature, that would mean that each year of development adds a month of maintenance work for the year that follows. While some features may be retired, the trend will still be for the number of features to grow, and the internally-developed features will take an increasing share of resources, requiring the team to grow in order to add new features.

   Any less-critical or more peripheral features that can have both their development and maintenance offloaded reduce that resource cost, even if that offload is never 100%.

A Roadmap of a Roadmap

So we have a simple roadmap, a barebones edition, and it probably won’t be the same roadmap we use a year from now. We may add RICE or MoSCoW, or we may grab a software solution like Trello or Asana.

Because if we execute well on the roadmap we have, we won’t be the same company a year from now; we will hopefully be a company that needs something more fully-fleshed and feature-rich, to accommodate a growing product with a growing number of satisfied users.

And that’s what the roadmap is for, in the end. To execute well, without getting in the way.