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 for your team or organization and already collected ideas in the longlist. OKRs 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). The one-pager we discuss is available in .docx and .md formats so that you can apply it to your ideas immediately. Bonus: template 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 ). 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. themeforest.net 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. Here is how the one-pager looks like Personalised “Buy again” reminder for soon-ending goods Project Name: Tatsiana Mihai ( ) / Customer Behavior Team Author: @tmihai Sales Org (#sales) Stakeholders: 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. Summary: 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. 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. Problem: 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. Impact: 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: 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/0/2023 1 x Data Eng1 x ML Eng2 x SWE1 x QA Mailing 01/08/2023 01/09/2023 1 x Product Des2 x CSM A/B testing (1st iteration) 01/09/2023 01/11/2023 2 x Data Eng1 x UX Res Product Development (Final) 01/09/2023 01/11/2023 1 x Data Eng1 x ML Eng2 x SWE1 x QA Risks: Risk Severity Mitigation Users will not perceive the new feature positively, worsening daily visit 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 two 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. 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. 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. 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. 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 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. 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 , 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. quantitative and qualitative experiments with data 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 and start overthinking. There are different ways to avoid it, and limiting the time for preparing the one-pager is one of them. analysis paralysis 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. 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. 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. 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., ) or additional tests. dogfooding 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. Also published . here

This story contains new, firsthand information uncovered by the writer.

The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch before making any investment decisions or decisions regarding your health or security. (Do not regard any of this content as professional investment advice, or health advice)

The On-Call Process: 7 Reasons It’s Not Up to Par and Ways to Improve

Read My Stories

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

How to Prepare a Winning Project for a Roadmap

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

The On-Call Process: 7 Reasons It’s Not Up to Par and Ways to Improve

10 Underrated Skills That Will Make You an E-commerce Rockstar

100 Stories To Learn About Online Shopping

10 Top Advantages of Node.js in eCommerce Industry

10 Most Popular Misconceptions About Email Marketing Automation

The On-Call Process: 7 Reasons It’s Not Up to Par and Ways to Improve

10 Underrated Skills That Will Make You an E-commerce Rockstar

100 Stories To Learn About Online Shopping

10 Top Advantages of Node.js in eCommerce Industry

10 Most Popular Misconceptions About Email Marketing Automation

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps