Design partners and product–market fit

A problem everyone knew, and a solution nobody had mapped

Coflow, as the product came to be called, set out to take the paperwork out of the appointment: send the right forms at the right moment, and file the answers back where the practice already looks. Coviu knew the problem existed. What it didn't yet know was which features made up a solved problem, or how the interactions should work. The first idea was to collect patients' answers and let the practice copy them into its practice management system.

Practices ran on paper and chasing. Forms went out, patients forgot them, staff chased, and appointments ran late because paperwork wasn't back in time. Responsibility rolled downhill: practitioners said their practice manager looked after it, practice managers said their receptionist did, and receptionists told us they spent all day scanning and typing. More than one practice had outsourced the data entry entirely. Some practice management systems could send forms, but one at a time, with an SMS fee each, and without writing back neatly to the patient's file.

Practices are also hard places to change. Staff turn over often and bring very different levels of technical and domain experience, and the minute-to-minute pace makes it hard to stop for a conversation, let alone set up a new tool. When a practice takes on a new product, with its setup, upkeep and new processes, that's a real win.

Coviu had tried to reach practices through cold calls from sales and product, and few wanted to take what sounded like a sales pitch.

Understand the space, then prove people will pay

My first two months were research: map the problem space, find the practices worth building for, and test whether the product could travel, including to the US market. Then keep those practices with us through the build, so their feedback shaped what shipped and their decision to pay told us whether we'd got it right.

A program practices wanted to stay in

Listen first, sell nothing

I started at the same time as our community manager, and we took a different approach: we weren't promoting anything. We listened to practices' struggles, came back to show them what their comments had changed, and iterated our concepts on their feedback.

Map how practices really work

I spoke mostly with practice managers, the people most likely to champion both the problem and a solution. Most had done the hands-on document processing themselves before handing it off, so they knew the pain and the value of fixing it. I spoke with receptionists to learn their workarounds and shortcuts, and with practitioners and owners, because practice managers would have to convince them to buy, so I needed to know what they valued.

As with any tool for a non-technical sector, a recurring challenge was learning a practice's tech stack from people who don't think in tech stacks. "Where things get stuck" could be as solid as an integration that didn't allow it, or as fixable as a setting configured wrong. I often became an impromptu IT helper for lower-tech practices, and that paid off: a friendly, easy-to-understand solution makes the adoption conversation easier.

Find the whole solution

The research changed what we set out to build. Copying answers into the practice management system would only move the typing from one place to another. Without true, automatic write-back to the patient's file we wouldn't save practices any time, and a partial solve wouldn't justify the effort of adopting it. The work became finding every beat an end-to-end solution needed, from sending the right forms to filing the answers away.

Ask for little, give back a lot

I wrote the offer to partners as a fair trade. We asked for a conversation, honest reviews of the designs, an admin to help set up, and candid feedback as they used it. In return they got a real say before anything was built, a setup tailored to how their practice runs, and the product to keep when the program ended.

Trust mattered as much as time. Their practice management system stayed the source of truth, nothing was written to a patient record without their confirmation, and they could roll back completely at any point. Starts were staggered one practice at a time, so each onboarding was unhurried and carried lessons from the last.

Run it in five stages

I set out a delivery blueprint, run with our community manager and a product manager: five weekly stages, each with a goal and a few touchpoints, coded by whether they happened as a call, a survey or in the background.

1. InitialiseAgreement to take part: a warm call, a profile of the practice, a booked walkthrough.
2. ExploreFeedback on the designs: a prototype walkthrough while engineering built the first slice.
3. OnboardSet up and using it: preparing their forms, going live, a first-use check.
4. StrideEmerging patterns: usability check-ins, targeted questions, real use patterns.
5. PositionSalability: a ranked feature wishlist, packaging and pricing, and how they'd describe it to a peer.

Check-ins scaled to how new the product felt: daily for the first few days, every few days after that, weekly from the second week. An open suggestions box ran throughout.

Turn conversations into evidence

Dozens of sessions across many practices produce more than anyone can hold in their head. So I built TRIFL (Tracking Research in the Interest of Future Learnings), a research tool for the three of us running the program, with a shared Google Sheet as its database. It tracked every partner's journey through the program and held a dossier on each practice. Its real job was a chain from conversation to action:

1. Transcripts to session logsA call's Granola transcript became a structured session log, filed against the event it belonged to.
2. Session logs to issuesEach log generated issue tickets, matched against that practice's existing feedback.
3. Issues to themesTickets were consolidated into themes, re-audited daily to attach strays, merge near-duplicates and split themes that had grown apart.
4. Themes to LinearAn issue or a whole theme could be promoted to Linear as a problem to solve.

Feedback about our product was kept apart from context about the practice's other tools, so themes stayed honest, and every status change and comment was appended, never overwritten. Partner status read in from the sales CRM each morning, so the program and the sales pipeline never disagreed.

Themes went straight into design. When "patients can't finish a long form in one sitting" turned out to be three separate problems (lost progress, forms that should stay editable, reminders that should say what's next), each got its own fix.

Ask what it's worth

The last stage asked partners to rank the features they wanted most, tell us how they'd package and price it, and describe it in their own words.

Partners who had onboarded their core workflows (new patients, bulk billing, consent and referrals) were very sticky, and didn't want to go back to manual processing. We asked how they'd pitch it to their practice owner, to see where the value landed for managers and for owners. For both, it came down to two messages: save time and money, and accuracy means compliance. That gave pricing and marketing language straight from customers.

Partners became customers

• 20design partners, with 3 to 8 sessions each.
• 90%of onboarded design partners became paying customers.
• 80%+of patients who started a form in the portal finished all of them, and practices reported far more forms coming back.
• Highshare of users said they'd be very disappointed if the product went away, the standard product–market fit test.

Once partners were past onboarding, the biggest themes were about trust. Many asked for patient submissions to be approved automatically, a sign they trusted it worked as claimed. They also asked for a forms library, trusting us to design their patient-facing materials, and form scoring, trusting us to replicate the scoring tools their field relies on.