How to Prepare a Winning Project for a Roadmap

Roadmap and project prioritization are fundamental stages in IT development. Which innovations are introduced first determines the product's attractiveness for customers and their competitiveness.

Often teams get lost when it comes time to select the most impactful idea, especially when the planning horizon is longer than three months and the product has not yet taken a strong shape or has found market fit. And while the main burden of decision-making lies with the product team, engineers can also contribute to planning to make it more predictable and efficient.

One of the best tricks I've used in my practice is preparing a one-pager for a project idea or feature. Creating a one-pager appeared in a business context when companies tried to present their business proposal quickly and focused, usually trying to fit everything on an A4 page. In engineering, the same approach applies: in a short document, state the key values of the idea that will achieve the company's goals.

The one-pager should be done after you have decided on the OKRs for your team or organization and already collected ideas in the longlist.

One-pager is not expected to provide deep edge case analysis or detailed system design, so preparing and writing it shouldn't take much time. For example, one of my teams set a limit of 3 days for cross-team projects to have time to discuss details with developers from other teams. A good one-pager only contains the sections that play a key role in making a go/no-go decision. I use a simple template to apply to product and purely technical improvements (e.g., configuring monitoring for legacy systems).

From an idea to a software project: DIY store

Let's see how each one-pager section can be filled in using the example of a feature for an online DIY store (the theme used in the post can be downloaded at themeforest.net). So, imagine your goal is to increase profits in the next half year by 15%. After the brainstorming, among the many ideas was a suggestion to remind customers of products about to run out to encourage repeat purchases.

Here is how the one-pager looks like

Project Name:Personalised “Buy again” reminder for soon-ending goods

Author: Tatsiana Mihai (@tmihai) / Customer Behavior Team

Stakeholders:Sales Org (#sales)

Summary: Personalised reminders to buy again ending soon goods can increase the monthly average transaction volume by 12.8% and D28 retention by 3% for web and 5.5% for mobile users.

The solution combines mailing campaigns, push notifications, and reminding components placed in the UI. Personalized recommendations and reminder settings are based on the internal solution for analyzing customer behavior. An MVP version can be delivered in two months; the solution requires four months.

Problem:After reviewing sales data for the past three months, it was found that 48% of regular customers make repeat purchases of low and mid-price products. However, only 12% of them return as soon as the necessary materials end, while the rest purchase with a delay of 2 weeks to 2 months.

Impact: The reminders will increase the number of timely purchases by 1.2% through mailing, 2.3% through mobile notifications, and 6.5% through in-app experience, amounting to $546K annually. Additionally, we anticipate growing user acquisition by 3.2% within six months, implying an additional profit of $120-$160K.

Solution:

Which parts of the system are affected:

App experience (web, native)

• A new embedded component that contains a product we recommend repurchasing. The component has the same design for all pages except the Home.
• Extend Notification management to support new reminders

Communication

• A new mailing campaign to send reminders for the products that end soon
• Extend existing email templates for invoices and monthly emails

AI

• Implement a new model that predicts the duration period for the items based on historical data
• Extend Data Labelling to allow annotators to add duration period with other product info

Milestones:

Risks:

Useful links:

• One-pager template / https://github.com/Tan--Tan/one-pager

And now, let's take a deep dive into each section.

Project Name, Author, and Stakeholders

A well-chosen name helps to catch the idea of the project from the first seconds and win the attention of stakeholders. When choosing a name, try to pick the one that would be the most familiar to a broad audience: it'll be pretty tricky to pitch the project if the name is far too vague or contains highly specialized terminology. Try to reflect on the key idea instead of dwelling on a concept that can be understood in various ways. Only rely on acronyms or fancy names if you are sure all stakeholders can get what you are talking about. The purpose of this document is to present what the project offers; you can always come up with a cool name later.

It's worth specifying the author of the idea to receive feedback from people who couldn't participate in an idea presentation session. Also, it'll allow stakeholders to reach out to the right person if they want to give the idea the green light. A team name helps to avoid confusion if there are similar projects in the organization. If the company is small. Just a name might be enough, but leaving contact info (email, group name in Slack, etc.) is always good to make communication smoother. Mainly it's handy in companies that give employees flexibility in editing profile names and picking messager nicknames or email addresses.

Stakeholders are optional but can be helpful when those who make go/no-go decisions about the project are not members of the team, and you want to be sure that the project will be in their field of vision.

Summary

The summary lets your stakeholders quickly assess the project's potential along with the name. Most often, those who make a final decision don't have much time to study in detail the implementation of each potential idea, and sometimes they are only interested in the impact reflected in key metrics. As Tanya Reilly rightly points the way in her book The Staff Engineer's Path:

If you can’t convince them in 50 words, you may not be able to convince them at all

I prefer to fill in the summary at the end, as I can put specific numbers I could collect from other sections. To check the summary's quality, try to highlight in bold phrases that you think should catch the eye of the reader. You are on the right track if more than half of such words are highlighted.

Problem and Impact

Perhaps the most valuable section for stakeholders. The project must either solve a severe problem, bring enormous benefit, or better both. But how to understand the size of the problem or impact? This is where analytical and monitoring data come in handy, and this is how the tedious work of properly configuring them pays off.

Monitoring is better suited to assess the technical condition of the product: how resistant it is to failures and how it copes with peak loads. From such data, it is usually possible to calculate the potential and actual financial losses in the event of a service failure. During the analysis, exciting data can come out about cost overruns on excessive infrastructure, unexpected memory leaks, or double charges for using 3P services. The impact of such metrics is to reduce financial costs, improve performance, and accelerate development speed. Quite often, such improvements are hidden under the hood of the product, which may create obstacles to approval by the product manager.

Analytical data is a storehouse of ideas for product improvement. By conducting various quantitative and qualitative experiments with data, you can find interesting patterns and validate hypotheses before actual development begins. Quantitative data includes raw and aggregated data generated by the product (data on transactions, the number of active users, etc.). They help you evaluate the potential of your idea in terms of current business performance and existing audience, as well as take into account the costs and risks that can be inferred from degrading metrics. This data lives either in your databases or in global reporting storage. If your company does not have a team responsible for post-collection data analysis, arrange with management for a self-analysis time before roadmapping begins.

Equally important are the qualitative product measurements. These include surveys, user interviews, prototype testing, product Persona creation, etc. You are unlikely to get fundamental impact changes from this data, but you can generate more hypotheses to validate. In addition, qualitative data provides more insights to understand user expectations better and improve the customer experience.

When choosing an idea based on data, always remember the OKRs. As groundbreaking as your project is to increase the number of new users, it's of little use for the OKR aimed at increasing sales. If the idea seems significant but goes against the team's goals, put it aside until better times or try to find a team whose OKRs are more suitable. However, suppose the project targets both the primary metric and improves some other one. In that case, it's worth reflecting all of them in the Impact section as it affects the project's total value and might be decisive in the last shortlisting stage.

It'll be a plus to indicate either in the Problem or in the Impact section how exactly the project will change the metrics in case of success in quantitative terms, as well as how long it'll take to achieve it. Long-term projects (2+ years) are best broken down into shorter periods (3-6 months) with defined success criteria for each so that you can reduce risks and drop the project if it underperforms.

Solution

The most familiar and expected section for engineers, as here, we want to see how the idea will be brought to life in detail. However, it's worth remembering that the purpose of the one-pager is to give only those details that will influence the decision regarding the project. Time is limited for writing and reviewing one-pagers, so instead of detailed diagrams and database schema designing, focus on showing changes in significant system components. This way, you will avoid discussions about implementation details that aren't important at this stage. You can create a separate document and link to it in the Useful Links section for code examples and listing all dependent services. The same rule applies when the solution involves data analysis or launching marketing campaigns, where code changes are minimal - only key hypotheses and strategies are included.

If several implementation options are equally well suited to solving a problem, try to evaluate them in terms of effort/value ratio and pick the best option. If such an assessment requires additional research, benchmarking, or a long review, add this stage to the Milestones section and indicate in the Risks what problems will arise if the wrong choice is made and how they should be minimized.

If your idea involves visual changes (for example, a new element in the user interface), it is better to sketch a prototype, as one image will replace several paragraphs of the description and give full context to the reviewers. For less visible changes, like infrastructure projects, you can draw a component diagram, abstracting away the low-level details.

Milestones

This section is optional at this stage because sometimes it's problematic to complete it with the level of detail you've had so far. To give the most accurate evaluations, one must be more or less sure of the solution, and we remember from the previous section that they are often unknown. However, if you can sketch out essential parts at least at a high level, you will greatly improve the quality of your one-pager and enable reviewers to make an informed decision about the project.

As a bonus, you better understand the project's chances of success. Often what seems like a small one-month-one-person project, when broken down into more specific parts, turns into a quarterly assignment for the entire team. This exercise also clarifies whether all the necessary roles are currently presented in the company and can support the project.

As well as, with the Solution, you shouldn't describe what needs to be done task by task. Stakeholders are interested in data about when the project can expect the first results and think about how best to distribute work to deliver (or fall) quickly.

If your company already uses some planning tool, you can replace the table in the template with any other format, like Gantt Chart or Miro Board. The main thing is to make it easy to understand how much time and people it takes to complete each stage.

Risks

There are no projects without risks. However, they often reveal themselves only when development has begun and there's little time to find a good solution. But it's also impossible to know all the possible risks in advance. What is this section for, then? At this stage, it's essential to know if there's a way for you to get out of a difficult situation and still achieve your original goals.

Sometimes in this section, together with the Milestones, it becomes evident that the project cost is too high. Factors such as external regulators, business seasonality, or internal company policies significantly affect a project's success and cannot always be influenced. For example, you want to do some cool upgrades to increase sales, but game-changing changes won't be ready until mid-November, the busiest business season. And if you can't get around this risk, the project will be put on hold until better times.

Problems like team inexperience or failed past launches also increase the risk of project success. Following a blameless culture without specifying names, titles, or teams is essential when filling out such concerns. The one-pager is a public document and shouldn't create an environment for an improper perception.

Risk levels and mitigation strategies must be realistic and achievable. Here, as well as with metrics, if you can't provide a plan to solve or at least minimize the problem outcome, you risk not only blocking the current project for an indeterminate time but also worsening the performance of active services and, most likely, increasing tech debt.

It's best to limit the list of risks to factors within the team's control. There is no need to enumerate factors like a reorganization or change of direction of the company: usually, when there are such big pivots, everything will be re-prioritized, and all mitigation plans will be irrelevant.

Useful Links

Of course, links can be placed directly in the text, but there is a risk of diverting reviewers from the information focused on the one-pager to less important details. Put here all the external and internal resources you used to prepare the document. It's worth adding a clear title to each link so that if the information is no longer available (for example, the logs can be moved after the retention period to another storage), at least the context will be preserved.