Know you're building the right things, with a discovery habit your team runs

Your team can build. The harder question is whether what you keep shipping is moving you toward the outcome you want. This is a short engagement to put continuous discovery in place as a habit your own team runs after we leave: a steady way to talk to customers, map the opportunities that matter, and test the assumptions behind a bet before the engineering time is spent. It’s for product teams and technical founders who ship a lot and want a reliable way to tell if they’re building the right things.

The problem this solves

Most teams we meet have plenty of ideas and the engineering to build them. What’s missing is a habit. Customer conversations happen now and then, usually when someone has time, and the assumptions under a bet stay untested until the feature is already live. Direction gets set by the loudest voice in the room or by whatever is technically interesting that week. Discovery becomes one person’s job rather than something the team does together, so when that person is busy, it stops. The result is high output and low confidence: you can’t say which bets really matter, and the work doesn’t compound.

What we actually do

We work alongside your team for a few weeks to set the loop up and run it together, coaching as we go:

1. Build an opportunity solution tree that ties everyday work to the outcome you care about, so the whole team can see what it’s building toward and why.
2. Set up a regular customer touchpoint: a cadence of interviews that keeps running on its own schedule instead of waiting for a crisis.
3. Put in place a way to test the riskiest assumptions behind a bet before you commit engineering, so you find out an idea is wrong while it’s still cheap to be wrong.

We coach the team through the real decisions you have on the table right now, so the practice attaches to your actual work and not to a slide deck.

What you leave with

• A discovery cadence the team owns and keeps running on its own.
• An opportunity solution tree that connects the outcome to the work.
• A working assumption-test loop: surface the assumption, test it, then build.

The point of a kickstart is that the capability stays with the team. When we step back, the habit keeps going.

Proof

We ran this way of working at Yepstr, a Swedish marketplace for youth jobs. Joni Lindgren came in as an embedded discovery resource and interim PM, helping the team form and test hypotheses before building, and by the end the team had taken it on themselves, ranking hypotheses ahead of their weekly prioritisation meeting. During that year the company’s revenue grew by 40 percent. Jesper Lekland, CTO at Yepstr, put it this way:

“The volume and quality of product improvements and strategic input she contributed during her tenure were truly unmatched in our nearly 10-year history.”

Yepstr was a hands-on, embedded engagement. This kickstart is built to leave the same way of working running with your own people. Read the full Yepstr story.

The team-owns-it angle shows up in other work too: a discovery effort gave 55degrees a grounded picture of who their users actually were to decide from, and a two-day training taught Avanza’s product managers to drive their own discovery.

Who it’s for, format, and duration

Who it’s for: product teams and technical founders who ship steadily but can’t reliably say whether the work is moving the outcome, especially where discovery has quietly become one person’s job.

Format: a short installation working side by side with your team, then a follow-through period where we coach the cadence on your real decisions until it runs without us.

Duration: a kickstart measured in weeks. We stay long enough for the habit to hold on your real work, then we step back so the team carries it.

Book a call

If your team is shipping hard and you want a steady way to know you’re building the right things, email hello@scilla.studio and we’ll book 20 minutes to talk through where you are and whether this is a fit.