Product and technology strategy
Working sessions and short engagements to decide what to build, in what order and on which foundations.
For founders and product leads deciding what to build next, with or without a technical co-founder.
When you need this
- You have a validated idea or an early product and need to decide what the next version is, and what it is not.
- The roadmap is a wish list. Everything seems important and nobody can say what matters most or why.
- A decision that is hard to undo is coming up: a platform, a stack, a vendor, a rewrite, a first hire.
- The launch is near and the operational side of the product, from payments to support to hosting, is still improvised.
What we settle
- Scope: the simplest version that proves the point, and the features that can wait without anyone noticing
- The product experience: the flows that matter, decided with the people who will use them in mind
- Architecture and stack, chosen for the team you have and the growth you expect
- Build or buy, for every piece that is not your core product
- The operational setup around the product: payments, e-mail, support, analytics, hosting, backups
- A roadmap in order, with the reasoning written down so the team can defend it later
A session day
Remote or in person. Two days when there is a lot to decide, one when the product already exists.
Morning
Scope and the people using it
What the product has to do for whom, and the simplest version that proves it. This is where most of the wish list goes.
Midday
Architecture and stack
The foundations for the team you have and the growth you expect.
Afternoon
Build, buy, and the setup around the product
Payments, e-mail, support, analytics, hosting. What you build yourself and what you should not.
End of the day
Decisions, written down
What was decided, in which order, and why. Open questions get an owner and a date.
How it works
One or two working days of sessions, a written result within the same week.
A first call
Where the product stands, what the next decision is, what you already know. Half an hour, no preparation.
Preparation
I read what exists before we meet: the deck, the prototype, the code if there is code, the feedback you have collected. The session is for deciding, not for catching up.
Working sessions
One or two days with the founders, remote or in person. We go through scope, experience, architecture and the operational setup in that order, and we do not leave a topic without a decision or a named open question.
Written decisions
A short document with what to build, what to skip, what to buy, in which order and why. Plus the next steps with owners. Written so that a new team member understands the reasoning a year later.
What it costs
A fixed price per engagement, quoted after the first call based on how much exists already and how many decisions are on the table. Follow-up sessions, for example before a launch or a funding round, are priced the same way. Numbers on request.
Questions people ask first
- What does a product strategy consultant do for a startup?
- A product strategy consultant helps the founders decide what the product should be and in which order to build it, based on what customers need. In my case the technology is part of that: scope, experience, architecture and stack are decided together, because each one limits the others.
- How is this different from hiring a product manager?
- A product manager runs the product every day. A strategy engagement settles the decisions a product manager would otherwise inherit or have to fight for, in a few days, with someone who has made those decisions as a founder. Many early-stage teams do not need a product manager yet, they need the decisions.
- Do we need a working product first?
- No. The sessions work with an idea and a deck, with a prototype, or with a product that is live and needs a new direction. What changes is how much I read beforehand and how much of the session is about the existing code.
- Do you also design the interface?
- I decide flows and interaction with you, and I have done that for products used daily by people who do not read manuals. I am not a visual designer. If the product needs one, the decisions from the session are what the designer works from.
- What happens after the session?
- The team builds. If it wants me to review progress, we agree on a follow-up. If it wants me to own the technical side for a while, that is the fractional CTO role. If a critical piece needs building and nobody is free, I build it.