Business Solutions Worksheet

A founder of a B2B coaching platform can articulate their product's features fluently but struggles to describe customer problems in the customer's own language. Their pitch leads with what the product does, not what it solves. Early sales conversations stall at the 'why should I care' moment. They know the product is good but can't get traction.

Frame this as a customer-first exercise, not a product exercise. 'Before we touch what you offer, we're going to spend 10 minutes inside the customer's day. What are they dealing with that makes them open a browser and look for what you sell?' Some founders resist this because they believe the product speaks for itself. Name that pattern directly if it comes up: 'The goal is to be able to write Problem from their language, not yours.'

Problem fields written in product language rather than customer language - 'they need a better coaching platform' instead of 'their HR teams can't track whether coaching investments are changing manager behavior.' Watch also for Impact fields that stay abstract ('it costs them time and money') rather than specific ('their coaching contracts expire with no data on whether anything changed, making renewal conversations awkward'). Thin Impact fields usually mean the Problem field is also under-specified.

Start with the Evidence column across all four blocks. Ask: 'For each one, where does this evidence come from - customer research, sales conversations, or your own assumption?' The answer to that question typically reveals which solutions are verified and which are believed. Then: 'Which of these problems did you find hardest to write from the customer's perspective?' That answer usually identifies the weakest product-market fit.

A VP of Sales at a mid-market SaaS company is a strong closer but struggles to retain accounts past the 18-month mark. Churn analysis shows customers feel the product was oversold - they bought a solution to a problem that wasn't fully theirs. The executive sells from capability, not from customer problem. Coaching is focused on consultative selling.

Use this worksheet to invert the executive's natural sequence. 'You're good at the Solution column. Today, we're going to build the Problem column first and not touch Solution until it's done.' The resistance is usually impatience - the executive knows what they offer and wants to get to it. Name that impatience as data: 'That pull you feel toward the Solution field is probably what your customers experience in their conversations with you.'

Impact fields that describe the executive's lost revenue ('we lose the renewal') rather than the customer's actual cost ('the team that was supposed to change their behavior hasn't, and the buyer is now explaining that to their own leadership'). The frame should stay on the customer throughout. Watch also for Solution fields that name product features rather than describing the mechanism by which the problem is resolved.

Ask the executive to read Problem 1 and Solution 1 aloud back-to-back. Then ask: 'Does the solution you wrote actually solve the problem you wrote?' That pairing check often surfaces misalignments that weren't visible when the fields were written separately. Then move to Evidence: 'What in your last five renewals supports or contradicts what you wrote here?'

A founder of a consulting firm offers three service lines that have grown organically over eight years. One is high-demand but high-effort; one is low-demand but high-margin; one was added to serve one client and has stayed on the menu out of inertia. The founder needs to make a strategic choice about where to invest but doesn't have a clear view of the problem-solution fit for each line.

Frame this as a comparative exercise across service lines, with one block per service. 'We're going to map Problem, Impact, Solution, and Evidence for each of your three offerings. By the end, you'll be able to see them side-by-side and make the comparison you've been avoiding.' The comparison is only useful if the Evidence column is honest.

Evidence fields that differ dramatically in quality across the three service lines - one has customer quotes and renewal data, one has 'positive feedback,' and one has nothing. That disparity usually tells you more than the other three columns combined. Watch also for the inertia service line to be defended in the Problem field with a very specific customer in mind - the one client who actually needed it.

After all four blocks are complete, ask: 'Look at the Evidence column across all three. Where would you put your own money?' Then: 'Which of these problems could a competitor articulate better than you can right now?' That question surfaces the competitive vulnerability. The follow-up is straightforward: 'What would it take to close that gap?'

A senior PM at a fintech company is building the case for a new dashboard feature. Their internal documentation is well-structured, but everything in it is written from the product team's perspective. A recent product review surfaced that the feature addresses a problem the PM team inferred rather than heard from users. The PM is resistant to re-scoping but open to examining the assumptions.

Frame this as a pre-build audit, not a critique of the current plan. 'Before the engineering handoff, let's map the problem-solution fit for the three core use cases. I'm going to ask you to write the Problem from the user's perspective - what they'd say if you called them today and asked what's hard about managing their account dashboard.' Start with the use case the PM is most confident about.

Problem fields that use product jargon or internal framing ('users need better data visibility') rather than user language. Watch also for Evidence fields that cite internal research (usage data, funnel drop-off) without any direct user voice - those fields conflate behavioral data with stated need, which are different things. A user might be dropping off because of a UX issue, not because the underlying feature is wrong.

Ask the PM to read their Problem fields and then tell you the last time a user said something that corresponds to what's written. If they can't name a specific conversation, the field is an assumption. Then: 'Where's the Evidence field thinnest, and what's the cost of shipping this feature if that field turns out to be wrong?' That question makes the risk concrete without being adversarial.