Product Prioritization: How We Move Fast and Build Things with a Small Team at Wethos
“Inside Wethos” written by: Claire Humphreys (Co-Founder & Chief Product Officer @ Wethos)
When building at a start-up, time is your most precious resource.
Why? Well if you’re at a startup it’s likely that:
You have hundreds (or thousands) fewer engineers than the incumbents.
You’re trying to build or win a market with little to no budget to do so.
You’re constantly sleep-deprived and anxiety-ridden with the amount of things that are on your plate.
What you’re doing should be hard - or else someone else would have already built what you’re building, won over the market and majority of customers, and then IPO’d and called it a day. That’s why time is so important - you have a finite amount of time, resources, and things you can try. Moving quickly and consistently doing things every single day is crucial for not only your survival but your success.
Paul Graham said it best: “Startups are like sharks. If they stop swimming, they die.’”
Fortunately, since start-ups are made up of small teams where every single person drives a measurable impact, you also have a clear advantage over the slow incumbents full of red tape. With less bureaucracy, teams can adapt swiftly to changes or ship faster without endless reviews. People are empowered by the impact they can make rather than afraid of the mistakes that could happen.
Being a small, agile, and highly passionate team can be your best advantage over competitors. But how do you get the wheels turning to create momentum and impact?
As a co-founder leading our product, design, and operations teams - I love reading tactical advice. Sure, hearing inspirational stories and theories can be motivational, but tactical advice like Lenny’s Newsletter or First Round Review has inspired so much of how we approach processes here at Wethos. This led our team to tackle our “Inside Wethos” content, to give a deeper dive into the decisions we’ve made to improve our product as a small team.
You asked, so here it is. Let’s dig into the product roadmap processes we follow as a team here at Wethos.
Rigid planning enables cross-functional clarity and speed
As a fully remote company, we offer a lot of flexibility for our team. Want to take off Friday morning and instead work Saturday afternoon? Or work in Excel instead of Notion because you can move faster that way? No problem. That helps people do their best work, which in turn creates a bigger impact on the business. But most people fail because expectations were misaligned upfront. So that needs to be paired with concrete structures that don’t change team-wide so there’s clarity and consistency for expectations. For us, that includes:
Quarterly OKRs, set at the company level by the founders, with only 3 metric goals for the entire team for the quarter paired with a full-team kickoff at the first of every quarter.
Kickoffs include a retro of the previous quarter, goals for the upcoming, and 1-2 work sessions where the team gets in the product and puts themselves in our user’s shoes critiquing the product and brainstorming ideas.
Each quarter we look back at our previous quarterly roadmap, what we ended up accomplishing and what the results were, and then review what the upcoming roadmap looks like for the next 3 months.
Yes, you can tell we like visuals and color over here
One important thing to note is a roadmap should be flexible and up to change if new information arises. They should also include stretch goals and priorities, assuming you won’t get to everything but can move priorities up or down based on the data throughout the quarter. That’s why we build ours in a “now, next, later” format with clarity on the stakeholders involved, goal size of the focus, and who’s leading.
Then throughout the quarter, we have immovable All Hands held every Monday and Friday where we look at progress on the goals, see show & tells of projects and feature releases, and align as a team. There’s also a standing Tuesday design jam to review the latest in Figma, a Wednesday roadmap meeting to review sprint progress and debate priorities, and a Thursday heads-down day for deep focus work. We have the same weekly structure no matter what, and each meeting is cross-functional in nature to make decisions together, quickly.
The reason we have these structures is because we actually want the consistency to drive clarity so there’s no question on when designs need to be ready, sprints should be measured, or even a recommendation for a re-prioritization should be brought up. The rigidity is meant to help us move faster so we spend less time on ad-hoc misalignment and more time creating the best possible work for our users improving our product.
Planning is important, but how you execute it is far more influential
If you’re anything like me, I want to understand the how a bit better. Sure, in theory, it makes sense to have all these structures and meetings, but HOW did you actually take each idea from pitch to launch quickly? First, it’s about structure to empower the whole team to individually move on their own track right at kickoff in order to get an idea to execution in a handful of weeks. We like to think of it as diverging and converging throughout so we can work async but stay aligned.
It’s important to note that not all features are equal in scope. For example, launching a new subscription is a huge amount of work and requires a full team effort. But just adding the small but highly requested feature of an invoice discount or changing the sign-up page content is less intensive, and only needs a few of the steps cross-functionally.
So you can see above that it all starts with the “PRD”. Ah, the beloved product requirement documents. They really are the heart of all the things we build, consistently updated as the axiom for the latest team-wide so we don’t have to waste time with meetings but instead have a living document from the problem statement to change log for what we’re building. For example, you can see we squeezed AI-generated proposals into a two-week sprint after spending a weekend investigating the feasibility of the integration, and writing out problem statements to user stories for future work in one place.
The PRD format probably deserves its own book, but in short, it provides a clear structure for capturing essential information related to the feature we’re aiming to build. Typically, it includes the following sections:
Problem Statement: Clearly articulating the problem we aim to solve with the proposed work.
Proposed Work: Outlining the solution for the problem statement and being open to an assumption audit and feedback. This step helps derisk the development process.
Success Criteria: Identifying the success criteria for the project and how it’s measured.
User Stories: These stories outline what the user needs to do to accomplish a certain goal.
Requirements
Designs
Change Log **this is important folks!
PII Data Compliance
Future work
I know what you’re thinking… nothing works that perfectly IRL
As a high-growth company, you get new data every single day. Things should change, and that’s expected. One of my favorite product leaders to learn from has been Brandon Chu from Shopify, who has detailed several frameworks for product teams to make good decisions and ruthlessly prioritize when needed. So we brought those into our weekly processes as bugs, optimizations, and urgent needs arose.
This matrix helps us determine the severity and frequency of the bugs reported. The more users affected or the placement of the bug should drive the priority, but this helps ground our team on what is most important when everything seems urgent and important at the same time.
In our product roadmap processes, we recognize the need to balance decision speed and risk assessment. This step helps us make informed decisions and minimize potential risks. By aligning decision-making processes with risk evaluation, we ensure that we are moving forward throughout the shared DACI responsibilities with enough caution and progress while considering the potential impact on our product and users.
Lastly, as anyone in tech is well aware, bugs can not be predicted. On top of that, PMs are likely inundated by their team’s “ideas for what to build next”. But throwing ideas and issues into Slack slows teams down and creates unnecessary chaos. So we created a form (Ghostbusters pic and all) for anyone on the team to submit bugs they find, optimization ideas or even feature requests as they arise throughout the quarter.
Conclusion: empower your team to try things quickly, so you can focus on the work (and not the process)
Of course, as each company and product is unique, so are the processes that work for you. But turning the process into muscle memory ensures you spend less time on it, and more time digging into the details to build the very best solution for the problem you’re solving.
Hopefully, by sharing what has worked for us, you can take a piece or two back to your team to continue to build out your structure and flow as you keep trying to change the world with whatever you’re building. We’ve learned that through collaboration, effective communication, and continuous improvement, we’ve been able to accomplish things we never thought were possible.
From launching AI-generated proposals in a week to turning thousands of lines of data from an Excel sheet into a simple template library - I couldn’t be more proud of our team and the product we’ve built.
Read more “Behind the Feature” product strategy articles from our team:
🛒 Why Our Proposal Builder is Built like an E-Comm Experience from Kristin Hodgkinson (Lead Product Manager)
⚖️ Balancing Optionality & Rigidity in Product Design from Noah Neustadt (Lead Product Designer)
✨ AI-Generated Proposals, The Future of Proposal Creation from Anay Gupta (Software Engineer) and Claire Humphreys (CPO)
🪢 Streamlining Operations with Embedded Proposals in Invoices from Gemma Horn (Director of Product Operations)