Selecting the most impactful ideas can be challenging, especially with longer planning horizons and evolving products. Engineers can play a key role in improving the process by utilizing one-pagers for Roadmapping. Let's see how this document condenses the idea's key values, ensuring alignment with the company goals and streamlining decision-making for successful execution.
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.
Red flag
If you first define projects and then tailor OKRs to them, you run the risk of missing out on market expectations,
falling behind competitors, and in the worst case, losing customers. Without mature engineering processes, roadmapping will
be inefficient as you will have to take on unplanned projects without being able to prepare a good system design and thereby
increasing tech debt.
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).
Bonus: The one-pager template we discuss is available in .docx and .md formats so that you can apply it to your ideas immediately.
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.
Good to know
Often, analysis summaries that make it easier to assess the impact of a potential project are available before you start planning.
Ensure you know where to find them and have time to familiarize yourself beforehand.
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
| Milestone | Start Date | End Date | Talents |
|---|---|---|---|
| Product Design and Prototype testing | 01/07/2023 | 01/08/2023 |
2 x Product Des 1 x UX Res |
| Product Development (MVP) | 01/08/2023 | 01/09/2023 |
1 x Data Eng 1 x ML Eng 2 x SWE 1 x QA |
| Mailing | 01/08/2023 | 01/09/2023 |
1 x Product Des 2 x CSM |
| A/B testing (1st iteration) | 01/09/2023 | 01/11/2023 |
2 x Data Eng 1 x UX Res |
| Product Development (Final) | 01/09/2023 | 01/11/2023 |
1 x Data Eng 1 x ML Eng 2 x SWE 1 x QA |
| Risk | Severity | Mitigation |
|---|---|---|
| Users will not perceive the new feature positively, which will worsen daily visits rates | High |
- Make the feature customizable in a user account with subsequent sign-off analysis - Test the feature on a small (2% or 1000 unique users) sample of users for 2 months |
| Not enough people to complete work in one quarter | Med |
- Make an MVP targeting one region and one application (Web) with the highest chance of increasing profits - Implement the Embedded component first - Enable an additional command (CSM) to set up a mailing - Conduct weekly reconciliation with planned dates |
| Users will not like the new UI components | Low |
- Conduct UX testing of multiple design prototypes with existing customers before development - Conduct A / B testing of several variations after the feature proves its effectiveness |
And now, let's take a deep dive into each section.
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.
Check the Example ↑
The words "Personalised" and "reminder" give an idea of the implementation details, and "Buy again" and "Ending soon" specify
which product groups are involved in the project.
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.
Check the Example ↑
Here we're highlighting a few things:
- the changes in key metrics(transaction volume, retention) that interest the stakeholders
- planned delivery time that is of interest to management
- a high-level solution to distinguish this idea from others
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.
Red flag
Stay skeptical when choosing refactoring or projects about replacing tech stack. If you can't prove in numbers that swapping
one code for another will improve some metrics, it's likely that the project is guess based, underperforming, and
should be re-evaluated.
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.
Good to know
In the case of evaluating a new product that does not yet have actual historical data, one pager can use the search for data or
attacks of companies running repetitive projects that can be found in the access operation.
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.
Red Flag
While exploring metrics and choosing an idea, it's easy to enter a state of
analysis paralysis
and start overthinking. There are different ways to avoid it, and limiting the time for preparing the one-pager is one of them.
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.
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.
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.
Good to know
Make sure you collect all the necessary metrics to track project dynamics. Add the very first milestone to set up monitoring if
metrics are not being collected.
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.
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.
Check the Example ↑
As you can see, the risk directly associated with the impact is rated High. The measures to prevent the consequences aim to reduce
the negative effect - do not involve all users, monitor if they turn off the function at a time when less significant problems are
solved by relying on internal resources (e.g.,
dogfooding) or additional tests.
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.