At ucreate we constantly challenge and re-evaluate our processes for building great products for our founders.
At ucreate we constantly challenge and re-evaluate our processes for building great products for our founders. As a result of scaling our organisation over the last year, our communication overhead has increased.
Due to this increased communication overhead, we needed to re-think how we could improve communication, product workflows and handover documentation across our ever expanding teams. We also had to factor in the challenges of multiple, distributed offices, which adds its own unique set of challenges.
In the early stage of your company, you don’t need that many processes because people can simply talk to one another. As a company scales and starts adding multiple teams, you need more formal ways of communicating across teams and to do that you need to start building repeatable processes — Hiten Shah
Whilst researching how other early-stage startups communicate their product vision and proposed features, I found a great podcast episode from Drift discussing their “one-pager” document.
Side note:💡Drift call it a One-pager — AKA Scope of Work (SoW), Product Spec, Product Requirements Document (PRD), Intercom call them ‘The Intermission’ and Basecamp ‘The Pitch’.
After listening to the podcast, I thought I would have a shot at creating my own document. Taking onboard our product principles, I created a template that would work for our Product Managers and our remote development teams.
In this post, I have put together an explanation of our Product Brief and also provided a free template for you to download.
It’s an artefact to scope and define a problem.
What it’s not, is a description of what you’re building, a list of requirements or a list of features. Too many people make the mistake of quickly assigning easy work items to their teams without involving them from the outset, listening to their suggestions, points of view or giving them the full product vision.
It’s extremely important everyone involved in each product team has a voice at the planning stage. Too many people are reluctant to speak up about their reservations during the all-important planning phase. By making it safe for objectors who are knowledgeable about the undertaking but worried about its weaknesses to speak up, you can improve a project’s chances of success.
As a Product Manager, this Product Brief helps frame, scope and communicate the customer problem to the team.
The goal of the Product Brief is to have a shared understanding of what we are building and why.
Side note:💡The audience, and the reader, aren’t necessarily you, it’s your team (engineers, designers, stakeholders, CEO’s, founders etc).
This is where you describe the problem you’re solving, why it matters, who your users are, and what it means to them.
Use the Jobs to be Done (JTBD) framework so you don’t just think about how it would be easier for somebody to achieve x in the product — but instead think about it in terms of what their ultimate goal is.
When _____ , I want to _____ , so I can _____ .
For example: When a new customer signs up to my platform, I want to be notified via email, so I can reach out to them.
This is where you expand on the story you told in the first section by discussing why this problem is relevant to your product. Discuss any lessons you’ve learned and the particular market that you’re in.
Provide some insight about your users (persona types) and the requirements that lead to the JTBD.
Include direct quotes from customers, visuals, the current experience right now and why it’s difficult or needs improving. This will help you demonstrate to the reader the context around the story that you’re telling.
Understand the impact that this product/feature can have. Create a concrete numbers based goal(s) which will be your definition of success.
For us and our individual teams, we pull out the particular product objectives and relevant key results to ensure we aren’t straying from our company and product OKR’s.
Think of this section as a high-level premortem.
Research conducted in 1989 by Deborah J. Mitchell, of the Wharton School; Jay Russo, of Cornell; and Nancy Pennington, of the University of Colorado, found that prospective hindsight — imagining that an event has already occurred — increases the ability to correctly identify reasons for future outcomes by 30%.
Flesh out any constraints you might have. Do you have particular legal or technical parameters to work within? Are there any risks that you can foresee?
Be mindful of the 3 main product risks — desirability (do our users want it), feasibility (can our team actually make it) & viability (does this make business sense).
You might not know all of the above at the time of writing your doc, but this is a live doc so keep adding to this section after the engineering and design team have fed back.
This is where you establish a rough deadline to solve the problem. Deadlines are a healthy forcing function for decisions and trade-offs and the constraints force creativity and prioritisation.
We typically work in 1–2 week sprint cycles depending on the complexity of the work. If we feel the element of work is going to take longer than 2 weeks we try to reduce the scope or break the work down into subsequent phases.
Again this may change after you have discussed it with your wider team. Keep updating it as you get more info/ feedback.
This is where you document and link to relevant information that you have. For example:
Basically, any detail that you have that could help provide more context for your team. Keep this as concise as possible with some bullet points and hyperlinks — you don’t want to overwhelm your team.
⚠️ This section should be complete once the solution/ feature has been shipped and in the hands of users.
This is where we capture our learnings, review section 3 (Goals), and discuss how we can do better next time. It’s also a good opportunity to review your premortem risk and constraints in section 4 to see which elements you didn’t foresee.
For this section, I would recommend arranging a meeting/ video call with your team. It’s important you get feedback from everyone involved. Ask yourselves:
It’s also worth noting I don’t intend to use this approach for each feature we intend on building (e.g. contact form or login) — but for larger problems, new products/features, flows and integrations I would suggest producing one.
This will most likely evolve as we use it more within each of our respective teams and projects at ucreate — so I'll be updating this post regularly with any new changes and improvements.
Got some feedback or questions on the Product Briefing document?
.jpg)
