How to write a Product One-Pager (w/ Examples)

+ How PMs should go about adding AI to their products

Hey BPL fam,

Let’s see what we’re unpacking in this mid-April edition:

• Top 5 things on my mind: There’s so much going on in products, AI & more. I thought I’d open up a window into some of the ideas swimming in my head.

• AI Line: We’ll look at my advice for PMs desperately exploring ways to add Generative AI in their products.

• PM Line: How to write an effective Product One-pager that your teams will appreciate. (with concrete examples - finally!)

• Growth Line: Why Product-led growth is more than just a free trial.

---

Top 5 things on my mind this April

What’s keeping my mind busy this week? Here are my top 5 in no particular order:

1. This masterpiece by Jason Cohen on figuring out your user’s real problem has left my head buzzing. Every entrepreneur & startup PM MUST read this.

2. Are machines truly coming? I wrote about how AutoGPT can open up a world of possibilities in product. It’s still not there yet. But the potential is scary.

3. This insane AI-generated home flythrough video shows you how fleshed out videos in the future can be constructed with a few images.

4. How AI can change games with personalized real-time voiceover.

5. 7 stellar copywriting tips by Jasmin Alic that everyone should learn

---

Advice before you add Generative AI to your products

Let’s admit it. Many PMs in Q2 are scrambling to add Generative AI to their products at the moment.

If you’re a Product Manager that’s been tasked to inject some AI into your product, here are a few of my notes:

1) Reset expectations.

AI is not a feature.
It's not a strategy either.
& very soon, it will no longer be a moat.

AI is an enabler just like how blockchain, HTML5 & mobile apps were.

Lead with how you solve a customer problem better with AI.
Not with "We're an AI-powered version of X, hence, we're better".

2) Identify the right problems to solve.

Stop treating AI as a checkbox to fill.

That opportunistic mindset will lead you to pick out use cases that are “easier” to implement as opposed to where they are most valuable.

Instead:

• Trust your PM instincts and talk to customers. Where are they currently facing the most friction? Are those problems related to feature discovery, strategic focus or really an area that can be plugged with an AI-based solution?

• What are most frequented critical paths that AI can potentially accelerate, reduce effort or save costs on? Identify & rank order areas where the most impact can be served.

• Figure out whether improving those areas will also lead to business impact e.g. churn reduction or expansion.

• Let’s say we’ve identified an worthy initiative - will this feature be behind a paywall? What kind of customer assurances would we need to commit to? What would the fine print look like?

• Think of AI as a co-pilot, rather than driving the entire experience. Acknowledge it’s imperfections & plan what would happen if it fails to perform.

Ex: Canva's Magic Write is embedded within the main design editor experience. The learning curve is minimal as it nicely embeds itself in flows users are familiar with. It speeds up presentation creation and is a compelling way for Canva to advertise it’s upgraded tiers.

3) Differentiate.

If your competition is also using the same LLM APIs as you, how do you plan to prove your product is better?

Answer: Training data.

Data that you solely own & protect or domain knowledge that you specialize in will prove to be an edge, even over larger tech players.

Ex: an e-commerce store that has years of siloed data on what kind of product descriptions & imagery converts best can help sellers sell more by helping them create better listings.

The downside?

Public AI models will learn & democratize those trade secrets. Samsung learnt this the hard way. Bloomberg’s GPT offering, on the other hand, had the right idea.

4) Know what's under the hood.

While "most" PMs won't be developing ML models or writing code, they will eventually play a part in conversations where basics of ML & LLMs will become a necessity.

Image Credit: Open AI

Ex: Knowing what can or cannot be solved by a model, understanding edge cases and road blocks, devising a data training plan & creating reasonable acceptance criteria.

Technical AI PMs will have to go even deeper. They'll need to understand model tradeoffs & tech stacks.

Moreover, LLMs have real problems PMs must be privy to: issues related to accuracy, ethics, privacy and scale.

I know PMs that wanted to build out a product based on ChatGPT’s APIs. However, their average daily concurrent user count was higher than what the API would have been able. That become a thorny bottleneck.

5) Inspect common use cases

Here are areas I see PMs using AI-assists in their product:

Image Credit: AIBusiness

• Summarizing content
  e.g. an edtech product creating a takeaway summary from a tutor lesson.

• Assisting data fills
  e.g. an e-commerce product auto-generating a product description.

• Facilitating user-generated content
  e.g. a social media product enabling users to generate unique avatars.

• Deploying chatbots
  e.g. a marketing platform like Hubspot allowing users to query CRM data with prompts.

• Analyzing large, complex data sets
  e.g. a customer feedback platform highlighting trends from a large volume of customer calls.

• Powering recommendations
  e.g. highlighting candidate resumes that match a job description best.

And now with the advent of AutoGPT, product teams may be looking at offering AI agents to augment their product.

Listen, I get it. Everyone wants to ride the AI wave.

Just know that it's your most human PM skills that will set you apart in the long run: empathy & compassion.

---

How to write an effective Product One-Pager?

Story time.

A while ago, I was asked to review a roadmap for an adjacent product team.

As I cycled through the various planned initiatives, I quizzed them with some regular questions:

• What problem are we hoping to solve?

• Who in our customer base are we solving it for? How do they solve it now?

• How did we arrive at choosing this problem? Is there a customer anecdote attached to this? What other evidence led to us selecting this?

• Why now? What happens if we don’t solve it? What are the stakes?

• What’s the customer reaction we’re hoping for if this is solved?

• What product or business impact are we hoping to strike with this? Is there a linked OKR? Does it help with time-to-value? Retention? Upgrades?

• Why is this the best solution? What else have we explored?

• Would this solution excite our customers? Would it excite us?

As I heard the responses, I saw worrying symptoms.

They were answers that you would hear from a team tasked to deliver an increment on time as opposed to a team dedicated to solving a problem.

Some quotes from the conversation:

• “We’re building this because many customers were asking for this.”

• “We chose this because our sales team said it was a dealbreaker.”

• “This is urgent because customer X was complaining a lot for a while.”

• “If we don’t build it, X will leave us.”

• “If we build it, X won’t leave us.”

• “We built this this way because X wanted it this way.”

• “We will build it this way now. Later on, we can make it generic for other users.”

• “This was the quickest solution given the timeframe we had.”

Notice the problem here?

There was little clarity on the core problem itself. The initiatives were chosen more out of fear of losing a customer rather than a deep understanding of customer’s pain.

Moreover, different people had different perspectives. Developers labeled initiatives as resolving tech debt. PMs justified them as revenue drivers. Sales folks saw them as a waste of time. And the marketing team had no clue this was even a focus.

I guess you catch my drift.

A core tenet of product management is to create sufficient alignment in the team, so that they know why an initiative is important enough to be pursued.

Sadly, verbal communication isn’t the best medium to capture this. Discussions are fleeting, perspectives change, words are forgotten easily.

This is where product one-pagers come into play.

Hang on. What is a Product One-Pager?

A product one-pager is a concise, (often) single-page document that answers fundamental questions about a specific product increment: the why, who, what and how.

I know it might seem like another document to contend with. After all, we PMs have our hands full already. However, this is one artefact that can save a LOT of time lost in alignment conversations and rework due to fundamental misunderstanding.

It typically includes the feature's purpose, target pain point, intended solution, success metrics, and other critical information necessary for stakeholders to understand and align on the product vision.

What purpose do One-pagers serve?

Here are 4 reasons why PMs should adopt the one-pager goodness:

1. Alignment: They help align leadership, development, design, sales, marketing, and other stakeholders on the product vision, feature goals, and expected outcomes.

2. Efficiency: A well-structured one-pager provides a quick reference for team members, minimizing the need for lengthy discussions or explanations.

3. Prioritization: One-pagers lend themselves nicely to prioritization discussions where all parties can debate using centralized information.

4. Documentation: One-pagers live between a user story and a full-fledged spec. PMs can use them as outlines to stem out further documentation & elaborate.

Disclaimer: Some people conflate Product one-pagers with business case documents. While one-pagers do address the business case, they also provide context into backstory of choosing the initiative, built-in assumptions & open questions - all necessary when engaging in implementation debates.

At what point should a PM write a Product One-Pager?

This is an interesting question.

Does the PM write this before the roadmap is developed? Or when a ticket is being filed in JIRA? Or when the use case is initially framed?

I personally feel the Product Manager should work on one-pagers in 2 cycles.

Initially, it should be developed when constructing a product roadmap, ensuring that each feature has a clear purpose and objective. The election of an initiative into a quarterly time scope should have some documented backing.

But it's also essential to revisit the one-pager when a feature is within a 4-week backlog horizon, refining the solution-specific details and making any necessary updates as new information may have come to light.

Should a PM write a One-Pager for every feature?

Not at all. A PM should reserve their one-pager creation energy for larger bets or strategic initiatives that will occupy significant development bandwidth.

Writing a one-pager for defects, UI improvements, minor enhancements & other changes that require trivial effort aren’t worth writing a one-pager for. I also wouldn’t write a one-pager for routine processes and flows e.g. 2-factor authentication.

Step-by-Step Guide to Writing a Product One-Pager

Here are the various sections that I’d recommend including in your one-pager document.

1. Feature Title

Start with a catchy and descriptive title that encapsulates the essence of the feature.

2. Target Pain Point

Identify the specific pain point or problem that the feature aims to address.

Questions to consider:

• Whose problem are we trying to solve?

• What problem of theirs are we trying to overcome?

• How intense is this problem? How frequent?
  

3. How do users solve this now?

Describe how users currently address the pain point or problem and why it's not ideal.

Questions to consider:

• What are the limitations of the existing solutions?

• How does the proposed feature improve upon the current situation?
  

4. Intended Solution

Clearly outline the solution that the feature will provide to address the pain point or problem.

Questions to consider:

• How will the solution solve the problem?

• What's the higher level user journey we're aiming for?

• How does it differentiate from existing solutions?
  

5. Inspiring Marketing Headline

Craft a compelling marketing headline that conveys the value proposition of the feature. This helps one visualize what the other side of the road will look like.

Questions to consider:

• Write a one-liner press release headline.

• Would this excite customers? Would it excite us?

• What message will resonate with the target audience?
  

6. Broad Components

List the broader building blocks necessary to develop and implement the feature.

Questions to consider:

• What are the technical, design, and marketing requirements involved?

• What kind of research and development exercise will we need to carry out for this?

• Will we need to buy or build this component? Pros and cons for each?

7. Why build this now?

Explain the rationale behind prioritizing this feature at this time.

Questions to consider:

• What are the potential consequences of not building the feature now?

• What happens if it isn’t solved in time? What are the stakes?
  

8. Supporting Evidence

Provide evidence that supports the need for the feature and its potential impact.

Questions to consider:

• Are there any user feedback, surveys, or data points that justify the feature?

• Have any competitors implemented similar features with success?
  

9. Success Flags

Define the expected outcomes and success metrics for the feature.

Questions to consider:

• What are the SMART (Specific, Measurable, Achievable, Relevant, Time-bound) outcomes you expect to achieve with the feature?

• What desirable user reactions would indicate the feature is successful?
  

10. Who will be involved?

Identify the teams and stakeholders who will be involved in the development and implementation of the feature.

Questions to consider:

• Which internal teams will be responsible for building, marketing, and supporting the feature?

• Are there any external stakeholders, such as partners or customers, who need to be involved?
  

11. Known Challenges

Highlight any known challenges or obstacles that may arise during the feature's development and implementation.

Questions to consider:

• Are there any technical, design, or marketing hurdles to overcome?

• Do you anticipate any resistance or concerns from stakeholders?
  

12. Assumptions

List the key assumptions made during the feature's conception and planning.

Questions to consider:

• What assumptions have you made about user behavior or market conditions?

• Are there any potential risks associated with these assumptions?
  

13. Open Questions

Identify any outstanding questions or areas of uncertainty that need to be addressed before moving forward.

Questions to consider:

• Are there any unresolved decisions or trade-offs that need to be made?

• What questions do we not have an answer today?

• What additional information do we need for further validation?
  

14. Known Risks

Discuss any known risks associated with the feature and how they will be mitigated.

Questions to consider:

• Are there any technical, design, or marketing hurdles to overcome?

• What could go wrong with implementing and releasing this feature?

• How will you address these risks during development or implementation?
  

15. What is out of scope?

Clarify what areas will not be included in the feature, helping to set expectations and avoid scope creep.

Questions to consider:

• Are there any specific features or functionalities that will not be covered by this feature?

• How will you communicate these limitations to stakeholders and manage their expectations?
  

16. Linked Goal/OKR

Explain which company or product goal(s) this feature will impact, ensuring that the feature aligns with broader objectives.

Questions to consider:

• How does this feature contribute to the company's overall strategy or mission?

• Are there any specific key performance indicators (KPIs) or objectives and key results (OKRs) that the feature will influence?

Enough theory. Let’s talk examples?

Sure. I’ve setup a Notion doc here with 6 examples of Product One-Pagers from various industries (feel free to duplicate the template).

Hope that helps you get your one-pager game on.

I’d love to hear your feedback.

---

Stop thinking to “hack” a Product-led motion in your product

Let me be clear: Product-led growth ≠ enabling a free trial.

PLG is not about a "weekend hackathon". Product teams attempting this underestimate what's really required.

It’s even harder for products that have historically been sales-led. They are carrying over months of baggage that will inevitably clash with a successful product-led layer.

Why am I saying this?

1. PLG demands all departments to be on board, not just product.

Sure, product managers drive the initiative. But they are many more cogs to take care of.

For example, a few years ago at Bayt (a job site in the Middle East I used to work for), the product team worked on a freemium product for job postings. Traditionally, Bayt sold it’s job posting packages through outbound sales.

The decision to opt for a PLG angle made sense because:

• We had massive inbound traffic on Bayt.com (top 15K websites in the world). If we constructed a self-serve journey right, that could lower cost-of-acquisition & develop a stream of paid subscriptions.

• The product was simple to showcase, understand & setup for recruiters (they had the motivation, capability & desire to utilize it).

• Increased competition was tightening the top-of-funnel. Traditional sales was also costly. A PLG layer was a means to lower friction in the buyer journey to ensure we kept. We also had some advanced recruitment products, so we planned to target engaged leads as upgrade prospects.

Now, as we were planning our PLG play, we had a number of workshops and brainstorming sessions.

Here are just *some* of the activities each department was engaged in to make this happen:

👉 Marketing had to re-configure their messages and CTAs.
👉 Sales needed to relearn a new lead process and understand how to deal with questions from existing customers and familiarize themselves with workflows pertaining to "product-qualified" leads. 
👉 CRM teams needed to be cater for free trial/freemium packages & update their lifecycle flows.
👉 Engineering & design needed to factor in a "self-serve" mentality in their experience-related decisions.
👉 Support needed to retool their scripts.
👉 Legal had to tweak the fine script & terms.
👉 Leadership debated on messaging, job posting limits, features etc.

Product is only piece of the pie.

2. Slapping an onboarding flow on a product primarily designed for sales-led conversations doesn't work.

The end-to-end user journey has to be analyzed to see if the product can stand on it's own. It may not mean a complete overhaul. But ensuring the product can independently acquire, activate & retain users takes bold decisions.

Plus, you have to iterate. A LOT. At Bayt, we actually lost revenue in the initial month. However, we saw promising dividends once we tweaked the feature discovery flows.

3. You need to start baking in a self-serve philosophy within the product.

This particularly applies to sales-led products. For example,

Previously, sales & finance teams may have been emailing invoices.
➡ Now, the product needs to be able to generate invoices.

Previously, sales & finance teams may have been collecting payments over wire transfers.
➡ Now, the product needs to be able to collect credit card payments.

Previously, development may have been configuring features & settings during the "implementation" phase.

➡ Now, the product needs to be capable of gating/un-gating features based on the purchased tier automatically. 

and so on.

4. The “Right” Product metrics won't track on their own.

You'll have to rewire instrumentation to start tracking things like trial conversion rates, PQLs, product-influenced revenue etc. This may not be in your existing dashboards. At the very least, you’ll have to setup a tools like Mixpanel, Chartmogul or Baremetrics to do this for you.

---

The attached diagram shows a basic checklist of things (NOT exhaustive) we had to cater for in our product-led experiments:

No, you don't need everything on the list at once. But you need to consider adding these sometime in your long-term roadmap.

💡 Most importantly: without leadership buy-in and failing to set this as an organizational priority, traditional sales-led orgs will face escalating internal friction when trying to integrate a product-led layer.

So, don't rush. Think before you PLG.