Reforge’s PRD (Product Requirements Document) Toolkit
Summary
Moola is planning to expand its B2B business intelligence product to cater to Small and Medium-sized Businesses (SMBs) selling niche industry-specific physical products. However, data-ingestion issues prevent the company from serving this audience efficiently. To solve the problem, Moola can use look-alike data based on their existing customer base and generate insights without a full conversation-recording tool. Besides, the company is building a product to help sales teams visualize sales performance and make data-driven decisions by recording their calls, and gathering critical sales insights. Moola will start with a small group of customers to test the product's pricing model. Lastly, the document outlines a Go-to-Market (GTM) plan for a new product/service in four phases.
This illustrative toolkit (Product Brief, Product Spec, and full PRD) was created by using the Reforge PRD components framework from the . The brief focuses on a new product build for Moola, a B2B business intelligence product that helps sales teams upload, tag, and analyze sales calls with prospective customers to better target qualified leads and synthesize insights.
You can review the below text in full to see how the Why and the What come to life in practice.
Today, we serve two segments of the market well:
- SMB customers selling SaaS products
- Mid-market customers selling SaaS products
We’ve been able to capture these markets effectively for two reasons:
- They use products like Loom, Zoom, and Google Meet that are easy for us to “ingest” as data.
- Our pricing model is significantly cheaper than competitors, who focus on Enterprise customers with larger sales teams (and higher ACV deals).
However, Moola doesn’t work for a variety of other customer segments. In the last year, we’ve seen significant latent demand (and inbound interest) from another high-potential segment: SMBs selling more niche industry-specific physical products (e.g, parts manufacturers, HVAC contractors, etc). Given our goals to grow to new audiences, this is a meaningful opportunity to capture an overlooked and underserved segment of the market.
Unfortunately, we can’t serve these audiences today because many of these businesses aren’t using reliable software for their sales operations, making it hard for us to ingest a single source of data to effectively analyze sales calls.
If we served this audience more effectively, two major strategic priorities could be met:
- Our growth ceiling would increase considerably, especially given how saturated the SaaS market is today
- We’d build new value within our existing core product experience that would be high value for existing customers too, which gives us an opportunity to increase prices down the line.
- In the last year, 24% of our inbound customers weren’t qualified leads because of data-ingestion issues
- When surveyed, the #1 reason for data-ingestion issues was that customers aren’t using (and don’t want to buy) Zoom, Loom, and other meeting competitors (most of their calls are done on the go by phone)
- Our research suggests that, if served, this segment represents an additional ARR of about $10M in revenue
- We only serve a segment of the customer journey today — analyzing calls after they’ve happened. We are well positioned to move up earlier in that journey to become an even more regularly-used tool if we can provide a way to capture sales call data even without the real recorded conversation.
- Links to relevant analyses and market reports with additional data
Quant:
- Adoption: We’re looking to get at least 10 exposed customers opt in for a 1 week trial so that we can gather data on usage and value prop
- Retention: 30% of those in the trial convert as customers, signing a year-long contract with us
Think of this as a “gate” to being able to do any additional work on this opportunity. We first need to see if we have the tech that can solve this problem effectively, and whether we’ve solved in a way that’s valuable and compelling enough to really activate and retain this new segment.
Initial hypotheses: To be refined and expanded with design and engineering
- We can help these offline-first sales teams get insights into how to optimize their sales without their own data by using look-alike data based on our existing customer base
- We don’t need to build a full conversation-recording tool because we have enough scale of existing customers that we can generate insights without it.
- New customers have to trust the insights to get value out of them — we need to test this first and foremost since they won’t be uploading their specific call data.
We’re moving into a new segment — SMBs who primarily sell non-digital products and tend to have sales calls not on a single recorded platform but instead make phone calls through their cell providers.
We’ll know we’ve met this latent demand if:
- Target: Any time we have an inbound request that fits this segment, we’ll walk them through this product experience on a first call
- Adoption: We’re looking to get at least 10 exposed customers opt in for a 1 week trial so that we can gather data on usage and value prop
- Retention: 30% of those in the trial convert as customers, signing a year-long contract with us
- Satisfaction: Since this is the first time we’re going to be testing with this population, we won’t track long-term satisfaction but instead will be doing ongoing research with the first 10 customers
Today, our product onboarding flow centers around getting teams to integrate their Zoom accounts so we can effectively use their recorded meetings as ingested data.
For the first pass of testing with this new segment, we need to validate the riskiest two hypotheses:
- Our technology solution: That we can effectively give insights to a new customer who hasn’t inputted any Zoom or meeting data purely based on the aggregated insights across our user base.
- Ongoing value prop and retention: That those insights are valuable enough that this segment will begin taking their own calls inside the app because the tracking and insights are so much more sophisticated than what they have now (usually just hand-written notes from a phone call if anything at all).
If either of these tests is debunked, we’ll have to go back to the drawing board for prospective solutions. Given that, we should design this as a test rather than assuming we need to build anything at scale.
Ultimately, we’ll only move on once we see the adoption and retention curves we want alongside a viable path towards monetization (more here in the experience section), but it’s likely we’ll need to test and iterate on some key component parts of the experience before we’ll get to conviction on the full solution. We should expect at least two sprints of designing and testing prototypes before we build any robust solution with engineers.
There are 5 main parts we’ll need to test around this experience, which I’m calling the 5 Is:
Here are rough sketches of how each of those components might look to give a sense of the flow.
- For intake, we really need to gather the minimal amount of data from a customer about the sales process that will deliver us an insight to generate back that they can use in their next call.
- We know from our existing call data that there are three main ingredients that matter most: a) what stage is this lead in? b) how expensive is this sale, and c) what industry are you selling in. With those three bits, we believe we can generate a minimally viable first insight.
- The insight is generated and shared so that it encourages the user to then immediately make a call with that insight in mind.
- We should test these first two parts (intake and insight) first because if we can’t get them right (ie…the insight isn’t smart enough or useful enough), nothing else downstream matters.
- Once the customer has received the first insight, they can make a call directly from within the app.
- This does two things: a) it records a new client entry into their Moola database, and b) it enables them to see the insight action directly from the call screen so that they’re reminded in real time.
- It also records the audio, since it’s calling directly from in-app.
- As in the app today, once a call is over we treat it as a normal data ingestion flow. We show the transcript and ask the user to input whether or not they’ve done the recommended action.
- Then, we ask them our normal questions about what else happened on the call so that they experience the value of the next generated insights and start seeing how Moola can help them for the next call, too.
- The invitation includes three additional insight actions and the CTA to save the call since it’s the first time
- When saved, we can return them back to the home dashboard where they can now search for that customer number or initiate another call with a new customer.
Risk | Mitigation |
|---|---|
**[Tech not good enough] **We can’t generate meaningful insights with the three prompt questions | - We’ll test the first two components first (rather than the full flow)- We’ll focus on a subset of customers whom we feel we can generate the best insights for (e.g, carpenters and HVAC manufacturers) |
**[Adoption and retention not strong enough] **We know from our current customer base that retention only happens after enough of the sales teams are using the tool together. Can we get enough folks to adopt that the purchase decision for SMBs becomes a no-brainer? | - We’ll focus on 10 key customers to start and give white-glove treatment to understand the biggest hurdles to the adoption process |
**[Line-of-sight to monetization fuzzy] **We can eventually convert these folks from a free trial to full customers with pricing that offsets call costs | - Before scaling any solutions here, we’ll do a split test once we’re past 100 customers to test pricing models. |
We want to help a new segment of customers - SMBs who primarily sell non-digital products - answer the big questions that give them visibility into their sales successes, failures, and opportunities.
There are few key components for each of our five Is:
- Intake
- Add a new client call
- Share three details about this client and the sale
- What type of product do you sell
- Where are you in the sales cycle
- What size is this deal
- Insight
- I want to see an insight that I can reasonably take into this next call.
- I want to be able to see another insight if this one isn’t helpful (up to three insights)
- Initiation
- Start a call with that client
- Same call functionality we have today for the call interface itself: end, hold, mute, and add tag
- See the initial insight that I should use on the call to help progress the client towards a win
- Intel
- Show transcript of call
- Show existing tags of call, using most popular tags for client size and stage of deal cycle
- We’ll show the most common tags across these three categories: feature, pricing, and ROI
- Show recommended next steps based on other company intelligence for size and stage of conversation.
- Invitation
- Add additional tags
- Save client call and transcript
Out of scope for initial phased work:
- Deep integration with existing free trial: Our intention is to enable a free trial for these users that is then gated by call volume (e.g, once you’ve called 5 clients and moved them up the sale cycle process, you’ll be paywalled to continue with usage), but we first need to ensure that the insights are valuable enough even in the free setting. So we won’t focus on any trial or paywall integration to start.
- Any integration with additional CRMs: This population is less tech-savvy in their operations to begin with. We already know we can solve the CRM problem once they’re onboard (we’ve done that well with existing segments). We know less about our ability to solve the insight problem, so we’ll focus there first.
- Any sales manager-led views: We’ll focus first on the sales rep themselves rather than any tooling for their manager to see broad performance. Adoption in our existing segments is surprisingly bottoms-up, meaning that once reps start seeing and feeling the value (the insights actually help them win deals), they bring it to the rest of their team. We don’t think this GTM motion is distinctly different for this audience.
Link to wireframe and prototype drafts, owned by design
We’ll be utilizing two main services that already exist in the rest of the product:
- transcript_tagging: this service allows us to fetch automated tagging for a transcript based on size of company, product industry and deal size
- tag_to_insight: this service generates a scored list of insights based on tags, which show up in the product experience as insight recommendations that customers can act on
Because we already have the main call UI, we don’t need additional infrastructure to record calls, but we do need to integrate the recordings with the insight flows, since we usually rely on integrations with Zoom and Google meet for that.
More tech-savvy customers tend to have CRMs that are integrated effectively with their sales teams, but this new segment rarely has formalized software they’re using to track customer and sales lifecycle. Given that, we are bypassing any CRM-integrations and will just “save” customers locally on a per-account basis. Part of the tech spec work here will be figuring out what data we need to store more permanently and where we can take shortcuts given we still need to validate this overall solution for customers first.
What is the feature rollout schedule for users? For each phase, how many users will we reach, and for how long?
We’ll take a three phase approach here with gates not dates, meaning we won’t move on to the next phase until we feel confident we’ve “unlocked” the previous phase and have a reasonable line-of-sight to scale.
Phase 1: Prove our insights are actually valuable based on intake data
Why: Derisks our primary hypothesis (our tech is good enough to produce meaningful insights based on intake questions)
Gates:
- End-to-end clickable prototype that we can show to 10 first customers who meet audience criteria
- Working service to generate insights based on intake questions (90% produce a > 80 scoring insight). We’ll ensure we’re selecting
- Moderated testing with 10 customers to get feedback on quality of insight data and de risk potential adoption hurdles
Phase 2: Successfully onboard and get 10 individual sales rep customers to solid adoption and retention
Why: Derisks our value prop hypothesis (customers find these insights valuable enough that they will call from within the app and use insights in first call)
Gates:
- 10 customers successfully onboarded
Phase 3: Close 5 new customers for full sales team adoption
Why: Derisks our existing adoption motion (since we know we won’t do white-glove service at scale, we want to test that sales managers will find this valuable enough to bring their whole teams aboard
Gates:
- 5 successful full sales team adoptions for new audience
Phase 4: Ensure successful monetization retention for additional 5 new sales manager customers
Why: Premature scaling is the death of successful new audience growth
Gates:
- Retention: 3 month retention in line with existing healthy customer retention (60% of sales team is DAU, 80% are MAU)
- Monetization: 5 new customers opt in for a 1 week trial — 30% of those in the trial convert as customers, signing a year-long contract with us
There are many additional phase to scale to this new audience thereafter (e.g, ensuring our insight engine is getting smarter and can cover more use cases over time), but we’ll cross that bridge if and when we get there)
What are the next steps or action items needed to accomplish this GTM plan? Who is the Directly Responsible Individual (DRI) for each action item? When does each item need to be done?
We’re only mapping out the development plan for the first phase of work, since there’s no point to mapping more out until we have a strongly validated first phase.
Phase | Outcome | DRI | Date |
|---|---|---|---|
1.1 | Hi-fi click prototype of end-to-end flow | Design (Charlie) | Sprint 8.1 |
1.2 | Insight generation DS prototype that we can test with 10 customers | (Alex) | Sprint 8.1 |
1.3 | Select and close alpha customer candidates | (Britt) | Sprint 8.2 |
1.4 | Moderated testing and synthesis for iteration | (Slava) | Sprint 8.2 |
| | | |
Archbee is a powerful documentation and knowledge management platform that helps teams create, organize, and collaborate on content seamlessly. With its user-friendly interface and robust features, Archbee ensures that information is easily accessible and efficiently shared across organizations. From capturing ideas and documenting processes to tracking project progress and onboarding new team members, Archbee is the go-to tool for professionals looking to streamline their documentation workflows and enhance team collaboration. As a reliable solution for knowledge management, Archbee empowers businesses to effectively manage their information assets and drive productivity in a professional setting.
