Do you find your product team doesn’t want to read your specs? Do others find them a lot less clear than you think they are?
Are you and your engineers missing estimates, or struggling to ship on time, because of changing requirements and surprise details changing context mid-build?
If you’re having trouble with things like missed deadlines, confusion and miscommunication mid-project, and not shipping your best possible work consistently, then it might be time to take a hard look at your product specs. They’re likely a big part of the problem.
The Product Thesis: A Better Way
Early in my career I was kind of winging it when it came to planning with my engineering and design teams. I had all kinds of documents all over, and I was inconsistent in the process from sprint to sprint and project to project.
Not surprisingly, it showed in the results we got, and the problems we had.
Fortunately, when I joined KISSmetrics, Hiten helped me learn a better way by introducing me to Josh Elman, who worked on product teams at Twitter, Facebook, and Linkedin. Josh taught me about the Thesis, which is a lightweight, efficient way to communicate all the essential details your product team needs.
It led to engineers and designers actually reading what I wrote in my specs, better ideas coming from everyone, and ultimately shipping more wins faster. It really was that transformative.
Now that I’ve used the Thesis on dozens of projects of my own, taught it to many of my clients, and tweaked it based on what I found worked best across many situations, I’m going to teach you how to write your own thesis for the next feature or product you build.
The Better Product Spec Alternative: How to Write a Product Thesis
By using Josh’s Product Thesis, I solved a lot of the problems I had, and similar ones I see with my coaching clients:
- Hard to find everything: Too many docs in too many places means key info can’t be found or is missed. The Thesis represents one place for all the most important answers for you, designers, engineering, and other stakeholders.
- Too long, didn’t read: Most people do not read 10+ page documents. The Thesis and its bullet driven structure forces you to get right to the point. My average thesis (excluding further reading) is only 2-3 pages, which led to everyone reading them.
- Missing key info: Compare the list of areas below to the product spec for your recent work. In my experience, most PM’s specs are missing roughly half of them, which is a missed opportunity for better, clearer planning and organization.
- Being Solution, not Problem-oriented: Too many specs I review are dictating outcomes all the way down to button placements. The best solutions come from discussion and debate with your engineers and designer. A thesis becomes a primer for solution discussions to ensure the most important & impactful opportunities are tackled.
When you pull all this information together in one, brief, easy to read place, it helps your product team better understand the why behind a feature and come up with the best solutions together. It helps motivate them more as well, because it helps them really taste and feel customer pain and opportunities.
When should I use a Product Thesis?
There are two simple things to keep in mind to determine if you need to pull everything listed below together for a Product Thesis:
1) For all significant projects
If a project or task will take less than a week’s time or fits in the “Quick Win” category of a simple ticket or two in your project management tool, then you do *not* need to make a Product Thesis.
Meanwhile, if you know for a project there will be:
- An Epic in your project management tool to tie a bunch of tickets together
- Enough design changes you know you’ll do some major user testing
- Any major changes to workflows or processes
- The project is a key part of your OKR/Quarterly roadmap
Then, those are exactly the times where pulling all of the things you’ve learned about the project and opportunity into a Thesis is the right move.
2) Before you start thinking or talking about solutions
It’s sooo tempting to start thinking about what you could do for customers. Yet, you shouldn’t do that. Pull back.
Instead, you need to pull all the information about the problem together for you and your team in your Product Thesis so that you have the guardrails for a deep discussion with your designer and engineers about:
- What’s possible to do?
- If we could wave a magic wand, what would we create for our customers?
- What can we get done within the time constraints and budget we have?
- What quick wins could fit in related to this?
- What should be de-scoped because it’s too hard?
- Design and tech debt considerations that come into play.
You only get the magical alchemy of building incredible products when you include your design and engineering team in the solution process. It’s what both Steve Jobs and Marty Cagan do.
And they and you can only combine to come up with the best solutions when you set the table with all the information everyone needs to truly understand the problems, opportunities, and constraints. It also engages and motivates them much better than dictating solutions to them.
Knowing all of this, let’s dive into what actually goes into a Product Thesis.
Want a FREE Product Thesis Template to use on your next project?
Sign up now and I’ll send you the template I’ve used for 10+ years:
What goes into the Product Thesis?
Below are the sections with explanations for why they’re each important. If you have any questions about any of them, please leave a comment on this post. You can also listen to this podcast discussion on the Thesis I did years ago as well if you like audio.
Remember: Stick to bullets! This should ideally be 1-3 pages long as that ensures that your team really reads it and can engage quickly. You can write up a separate memo like the Amazon Press Release style for marketing and other stakeholders after you and your product team have settled on the solution & scope.
The goal here is to clarify your thinking, make sure you didn’t miss anything, and set the stage for a great discussion with your engineering and design partners on what is possible within the constraints and opportunities you outline.
To this day, 15+ years in my career and over 10 years since that fateful meeting with Josh Elman, I still start every Product Thesis I write by copying a template like the one you can sign up for on this post.
Okay, here’s the sections of the Product Thesis and why they matter:
Product Thesis Title Here
1) Why are we working on this next?
This is first for a reason: This is what gets others excited and bought into what you’re building.
Every company, and especially startups, are resource constrained. What you choose to build affects your company’s bottom line, your standing in the market, and what your team thinks of your judgment.
You need to succinctly get everyone reading this on board to why this is the biggest problem or best opportunity.
I try to have a mix of qualitative and quantitative data here including:
- Mandates from the leadership team to focus on this area
- How sales needed it for a big customer, or how many customers are begging for it
- A stark number that paints the clear picture and creates urgency (like an alarming churn rate, big dollar value deals the feature is for, or clear weak points in a key funnel)
The more your designers and engineers can understand why this matters, the more interested they will be in working on it, even when it’s not the hottest new tech or feature.
2) When and how do people use this feature?
Most products end up having a variety of different users and ways that people use the product. To help your team better design a specific feature for the right part of your customer base, you need to detail who this new feature is for.
Be specific! A use case section that is just something like, “As a marketer, I want a mobile app so I can access my data away from a computer” is total weaksauce. Instead, provide the kind of context and detail that paints a picture of the situation:
- “On their way to work on the subway, content marketers like to check how their blog traffic is doing for items they published that morning or the day before. It helps them get into work and know how they’re doing before they sit down. If a number is low, they may try promoting it extra to try to raise the number. If the number is high, they may share the win with others on the team.”
Could you picture that situation in your mind? Can you see Jenn the marketer opening an app on her iPhone while sitting on a subway car? I bet you could. Your team can, too. They can also then start thinking about what the perfect (not just good) solution would be for them.
Write out as many use cases as you feel are needed. I often have as many as 4 or 5 detailed cases for a big feature, especially when our product has multiple personas.
3) What Problems do we need to solve? (in order of priority)
Features are really solutions to your customer’s problems. It doesn’t do any good to build a feature that doesn’t actually solve the problem, so it’s important to detail what problems you need to ensure the solution your team creates addresses them.
Problems should either be existing problems your product has (especially if you’re iterating on an existing feature) or the problems related to the use cases you just described above. Some example problems may be:
- Performance Problem: Customers are experiencing frequent crashes (57 incidents last week). This feature is critical for customers and they are constantly having to refresh and start over, losing their work in the process.
- Design Problem: 20% of support tickets are due to customers are having issues with the current UI. They can’t find key features that exist that they say are important to them (Include a markup of the interface to show these.)
- New Problem: Customers spend hours every week manually copying numbers to a spreadsheet and making their own visuals for their VP. If we automatically make those reports, we’ll save them time and can then have the VP see our branded reports frequently.
I usually write out 5-7 problems that a feature addresses in bullet form. If it only applies to some of the use cases I described, I’ll specify that as well.
Remember to also rank the problems, so that the most important issues get the most attention. When ranking, remember Olsen’s Hierarchy of Needs as a helpful framework on what matters most: (Note – the bottom is most important like Maslow’s Hierarchy)
This ranking matters most when it’s time for tradeoffs. A detailed ranking of problems will help you make sure the right things get done and avoid being de-scoped, while less important, and difficult items quickly hit the chopping block.
4) How much time is budgeted for this project? When do we need to be completed with this by?
One of the additions that I’ve found has been important for most product teams, but wasn’t in Josh’s original lesson for me was to call out the time / budget for a given project.
This is important to think about for 3 reasons:
- Your engineering and design teams need to know how big a project this can be, so you can talk tradeoffs and scope effectively with them as you collaborate on coming up with the best solution for this phase of the project.
- You are consciously choosing how long you work on this project versus the other potential projects and goals you have. You have finite time and resources, so you need to decide what is worth the largest investment. RICE and similar frameworks can help with this, as well as thinking about these kinds of tradeoffs:
- Your stakeholders need to know when you’ll deliver this project, so they can plan accordingly for how they’ll act based on this launch.
In particular, sales and marketing teams can become very frustrated by majorly missed deadlines. It not only impacts their planning, but it critically affects their ability to hit their numbers.
The simplest way to avoid these kinds of issues is to start making the time allotted for a project something that is defined at the earliest stages of planning. That’s why in this section the goal is to very succinctly, in 1 sentence in 1 bullet define:
- How many weeks you have for this project and a target ship date (or time when it’s in QA and ready for your deploy process.)
Yes, you may want some flexibility depending on what you decide is important, and that’s exactly the point; time spent on this project should be an active part of the discussion. Otherwise, I’ve seen too many cases of projects that run much longer than planned, or scopes that get completely out of control, preventing essential other projects from happening.
5) What are Future Considerations that must be accounted for?
This section is all about avoiding hearing from engineering, “I wish you had told me that before we built [X]!”
Very often, when engineers build something, there’s a few ways they could do it. When you give them a hint of what may come in the future, or that was de-scoped early in this process, they can make more intelligent decisions about how they build things now. A small change now can make a revisit to the feature *much* easier 6 months later.
Depending on the feature, this could be very short or long section. If there are things you know are not going to make the first version of this feature, but expect will be needed to be added later, be sure you tell your team!
You can also use this section to note things that originally were planned for, but after discussing with your team, you de-scoped. This is how you turn your Product Thesis into a living document that is useful to reference at many points in your product development process.
The bottom line: Balancing the present and the future is a constant struggle for your product. The best thing you can do for your team is give them the key information you know so they can do their best to balance their work against the present and future as well.
6) (Optional) How does this tie back to this quarter’s OKR(s)?
This should be a single sentence explaining which of your OKRs this project relates to, why it does, and a link back to your OKRs document or tool.
The point of this is to make it obvious to anyone seeing your Product Thesis how you see this contributing to your OKR(s).
If you don’t have OKRs, obviously ignore this section. You can also include this in your Why section in the intro if you prefer, but I’ve found that explicitly calling it out like this is helpful for others (like say an executive or your boss). As with everything in the Thesis, use your best judgment for what fits your team and company.
7) What is our KPI or Metric for this Thesis?
This is one of biggest gaps in most product specs I’ve reviewed, and it’s critical that every Thesis have some form of this.
You should ask yourself, “What would make this new feature a success?” A KPI (Key Performance Indicator) is the most common way to determine that success since ideally you will tie the success of the feature to one or more of your company’s key metrics.
It’s okay to have more than one KPI, but keep it simple, or there will be too many things to measure. When I’ve had multiple KPIs for a feature they’ve been things like:
- Support requests will drop by 90% for this feature after relaunch.
- Usage of our app’s [X] feature will grow by at least 50% after relaunch.
- Because this feature affects the sign up flow, we expect a 5% lift in conversion after this launches.
You will fail sometimes, but by forcing yourself to quantify what you expect to happen, you will keep you and your team honest. By setting a number that you must hit, you can also know when you should go back and iterate further. You’ll also hone your instincts on what creates wins and what does not.
Further, by identifying the metric up front, you make sure any tracking that needs added to the product is done while your engineers build it, saving them time going back later, or lacking a baseline after launch.
Most important for this section is simply the act of committing to measurement. Shipping is not success as a product manager, but without calling out measurement in your spec, I find most PMs never get around to measuring a lot of what they should for their features.
8) Who are the stakeholders and how/when do they need to be informed?
When work gets busy, it’s easy to forget about stakeholders and other people you don’t work with every day. That’s how you end up forgetting to loop someone in when they need to be.
This can end up hurting you and your company in a variety of ways:
- Your launch may flop, because marketing had no time to prepare a press push or launch announcement.
- Sales misses out on some deals, because they don’t know what is available soon enough to close a key, tightly fought deal.
- Other teams may step on your toes, because they didn’t know what you were working on.
Avoid shooting yourself in the foot by thinking through who you need to involve in this project and how. Keep it simple, much like the OKR section, by simply:
- Listing out the Name, Department, and when and how you expect them to be involved in the project. One name per bullet.
Then, make sure you stick to that plan, and confirm with the stakeholder you agree on how they’ll be involved and what they need to know.
This is a checklist to remind you who to speak with and helps you make sure you give them all the time and information they need to coordinate with you effectively.
9) Further Reading:
Your main document shouldn’t be longer than 2-3 pages, so Further Reading can act as an Appendix for you. This section allows readers to easily jump into an area that is most interesting to them and see the data or evidence that backs up your Thesis bullets.
Add links to customer research, call recordings, feedback, quotes, usability testing, surveys, survey analysis, specific analytics reports or queries, etc. While your main document should be no more than 3 pages, Further Reading can be as long as you want.
Remember: You want all the detail you can without the fluff and verbosity that makes engineers and designers skip reading it. Further reading is a great place for specific information that didn’t fit in the above sections and may be relevant to only certain team members.
Who should I share this with and when? How do I use this with Stakeholders?
The number one goal of this document is to help you bring clarity of thought and a clear definition of the project to set up a healthy discussion with your design and engineering team. Together, you’ll work out what the best solution is based on the constraints, problems, and opportunities here.
The secondary goals of this document and process is to:
- Help you identify weaknesses in the work you’ve done to define this (i.e.- Don’t know something? Go find out.)
- Start thinking ahead for how to involve marketing and other stakeholders at the right times.
- Give you an organized place where you have all your research and thoughts in one place, so you can share all or part of it when it’s helpful in stakeholder discussions.
This then makes it easier to share with other colleagues when it makes sense. Once things are solidified with your core product team, it often can be helpful to share your Thesis with some of the stakeholders you noted in section 8; the same use cases and problems that inspire your designer can also inspire marketing copy or sales pitches.
Conclusion: A great Product Thesis is a high leverage asset for PMs
Creating a great product spec clarifies your thinking, organizes it clearly for others, and helps you avoid many of the most common pitfalls of the product development process.
The best way to ensure your product specs are consistently high quality is to use a template to guide you. That way, you don’t forget anything, and others get used to a consistent format from you.
If you’d like to upgrade your product specs, and want to start using the Product Thesis, I have created a template you can use now. Simply enter your email below to receive the template straight to your inbox:
Image credit: Organization icons created by Freepik