One-Pagers (Product Specs)

One-Pagers (short product specification documents) are an important part of product development. Crystal clear thinking upfront can often save multiples of that time down the road when you don’t have to throw away expensive high fidelity design or production level code.

One-Pagers also allow teams to get on the same page (particularly in distributed, async orgs) before work actually begins. These documents help clarify the “why” behind the work and the scope of a project before the team starts to build the actual software to solve a problem.

Here is a format that I like, and have used in the past. I think it’s helpful to have a consistent format for your company that is also lightweight. If it’s widely adopted the team will also find these easier to consume in the future.


Feature Name

I like to start all project One-Pagers with a short, consistent table so it’s easy to parse. If you’re using a tool like Notion a number of these buckets can be selections over free text.

DescriptionOne sentence description of the feature
GoalsWhat is the user goal? What is the business goal?
MetricsWhat will we measure to determine if the project is successful or not?
ResponsibleWho is the person or team directly responsible for the project?
ImpactSimple T-Shirt Size (XS,S,M,L,XL)
EffortSimple T-Shirt Size (XS,S,M,L,XL)
UrgencyIs there a hard deadline?
RisksExplicitly list some of the key risks (1-2 things typically)

The Problem

Before working on the the solution, start by clearly defining the problem so that everyone on the team has a clear understanding of what we are trying to solve and why we are trying to solve it.

  • What is the user or business problem we are trying to solve?
  • What is the evidence of this problem (user feedback, data/chart, intuition)?
  • Why is this problem an important problem to solve now?
  • How does this problem fit in with our overall company goals?

The Solution

The most important thing to define in this section is what is in scope and what is not in scope for the first shippable version of the solution (or minimum viable product, MVP).

  • For more complex experimental features, some design exploration and prototyping may be necessary. In these cases it’s good to put some guardrails around the prototyping so that the design space is constrained.
  • Be practical about the feature scope based on your knowledge of the technical constraints, team capabilities.
  • Summarize the user flow for the MVP so that engineers are not designing UX on the fly.
  • List all open questions (design or engineering) clearly so that the team is on the same page about things that we need to solve through experimentation.

Enhancements

There are always good ideas that don’t make the MVP and it’s good to record them to show how the feature could evovle but also constrain the first version.

  • List out feature enhancements in rough order that you will come back to later and prioritize.
  • Create a task (e.g. in Asana or Notion) for each distinct additional piece of work and tag it with the feature name, so it does not get lost after implementation.
  • When deciding what to prioritize in the future you can then pick between an enhancement for an existing feature and a new feature more systematically.

Before you launch features there should be some sort of launch plan and checklist to make sure that balls are not dropped like QA (testing, performance), event logging, product marketing plan (customer emails, blog posts, marketing), support documents, AB tests, or a staggered rollout.

Although you can choose to include these in more detailed product specs they are often similar and I reserve these for more detailed execution documents vs. these simple product one pagers.

I don’t recommend you keep these documents up to date after shipping the first version (adds too much overhead). Features evolve during development and the purpose of this document is to act as a central starting point to get everyone on the same page and the source of truth usually moves to whatever product/project management tool you use for your roadmap.

Product Development Practices

This post is a collection of some product development practices that I think are valuable. It’s not meant to be an exhaustive list, just a collection of thoughts.

Goals and Planning

“Plans are worthless, but planning is everything”

Dwight Eisenhower, 1954

Planning allows teams to get aligned and having clear goals, priorities and metrics for success creates a shared understanding of what is important across an organization. If more people understand the ‘why’ behind goals and how these goals ultimately roll up to the company’s mission then the product details reflect these goals and values. It feels subtle, but over time translates to better, more consistent product quality.

The best organizations plan but are also able to abandon plans or adjust quickly based on new internal or external data. Many large organizations become rigid and slow, although perhaps more intentional, which is often the argument against medium or long term roadmaps.

Roadmaps: Now/Next/Later

All teams should have a public roadmap (an extension of planning) and my favourite framework is Now/Next/Later because of its simplicity.

Roadmaps should be lightweight, flexible and become less precise as they look further in the future. When all teams use the same format (and this is accepted across the organization) it’s easier to roll up work across teams. It’s even easier if all teams to use the same tool (particularly for managers of multiple projects), or if there is seamless two way information transfer between roadmapping tools.

To help determine priority, which is ultimately an ordered list, I like to use an Impact vs. Effort framework (taking into account Risk as well). Impact is the potential value to users and the business, and Effort is how hard it is (T-Shirt sizes like S, M, L, XL are an easy way to visualize).

Top 3 Things

At every level of the company write down the top three projects at any point in time and share them publicly.

This is a simplification layer on top of roadmapping to make it easier for folks outside the team to understand their work, quickly. It also acts as a forcing function for teams to decide what’s most important It’s a process can scale across large organizations and roll up nicely from teams, to divisions to the top of the organization.

The top three things should be specific, have a clear outcome and refreshed at the end of every sprint or planning cycle (typically 2-4 weeks).

Shaping (“One Pagers“)

Thinking is cheaper than making, and crystal clear though upfront can save multiples of that time (and cost) down the line.

One pagers should shape problem spaces into a set of solution spaces and assess the viability of these solutions to solve a set of user or business goals. It’s a collaborative document typically assembled by product managers with engineers and designers contributing. This process helps build alignment between the team, allows multiple solution spaces to be explored, and ultimately results less discarded work and clearer requirements for design and engineering teams.

These documents are short 1-2 page descriptions of the feature that anyone across the organization can read (as little jargon as possible) and get a sense of the value and the scope of the project. They should cover the goals, metrics, problem space and options for solutions with a recommendation of an MVP.

Burndown Lists

Burndown lists are simple, ordered lists of all the tasks/bugs/polish that need to be completed before we launch a feature (can be any version of launch – internal or external).

These are typically assembled when a large feature gets close to launch and the ‘launch line’ is a moving target. Once everything above the launch line is completed, the feature can launch. It’s an excellent system to help with prioritizing what is necessary for launch in a binary way, which simplifies the decision process.

Burndown lists a simple, visual powerful and motivating tool for folks who are getting ready to launch a feature. Checking off things that get you closer to the launch line is very satisfying 🙂

Feature Reviews & Retros

After launching a feature (especially Large or XL: projects) it’s important to get together to reflect on the project. This allows teams to step back to reflect on the process, celebrate their work and their colleagues and codify learnings for the next project. I prefer doing retros once we know the outcome (metrics) of the feature to see we met the intended goals.

I could also see an argument for separating this into two pieces, the process and the outcome as there are cases where quality product development (for a risky feature) do not achieve goals. In these cases it’s important to celebrate good work, and share learnings. If taking risk is not accepted by the organization it will be avoided, which stifles long term innovation.

Dogfooding

Use your product. At every company I’ve worked at, a significant portion of the people who work on the products are not regular users of the product outside of their daily work.

Especially for consumer products, the more people at the company who use the product like ‘real users’ the better the product will become. Using products creates empathy for customers, because you’re a customer, and helps improve product sense (although increases bias) and find corner case bugs.

It’s also a powerful cultural force, and I think that leadership, in particular, should lead by example by being power users of the product (s)– the product something everyone in the organization has in common.