Research and roadmaps for product teams
Training and coaching for design and product teams who want to ask better questions before they build, know why everything on the roadmap is there, and measure what matters rather than what’s easy to count. It brings twenty years of product and design practice together with systems thinking.
Where product teams get stuck
Early stage or established, the same gaps tend to show up.
- The roadmap is really a list of requests from whoever asked loudest or most recently.
- Research happens after the decision has been made, to back it up.
- The team ships constantly, and nobody can say with confidence which of it made a difference.
- The strategy deck says one thing and the sprint board says another.
- The metric everyone watches keeps going up, and something about the product feels less trustworthy for it.
- Deadlines are set before anyone asks what the team can actually carry.
- Problems surface after launch that the people closest to users saw coming.
- Your designers and product managers want to do research properly and have never been shown how.
Most of this comes from building before anyone has asked why, and measuring what’s easy rather than what matters. More speed and more data rarely fix it. Better questions, asked earlier, usually do.
What I teach teams to ask, and why
Design taught me to challenge assumptions and stay with the problem before reaching for a solution. Systems thinking taught me to look at what a product rewards and what it sets in motion. These are the questions that bring the two together.
Teams often solve the problem in front of them rather than the one causing it. Starting from the problem, not the solution, is the oldest lesson in design and still the most skipped.
Every item should trace back to the strategy and to a real need. If nobody can say why, it’s usually there because someone senior asked for it.
Every product shapes behaviour, in the people who use it and in the team that builds it. If you don’t decide what it rewards, the metrics will decide for you.
The people most affected by a product are often the least consulted, and they tend to see the risks first.
A feature that lifts one number can quietly erode trust somewhere else. Thinking a step or two past launch is where systems thinking earns its keep.
Activity is easy to count and outcomes are harder. Good measures show whether people are better off, not only whether they clicked.
A roadmap that ignores capacity burns out the people delivering it, and a burnt out team makes worse products.
From what you learn to what you ship
Research shows you what’s true and the roadmap decides what to do about it. Measurement closes the loop by showing whether it worked, and most teams only ever get trained in one part of that.
Research that asks the right question
Planning research around a clear question and a clear why. Interviews that get past polite answers, synthesis that turns what you hear into decisions, and market and competitor analysis that shows where the real opportunity is. Alongside it, simple systems mapping, so the team can see who and what the product touches beyond the user in front of them.
Roadmaps built on purpose and capacity
Outcomes tied to the strategy and targets, with a way to prioritise that weighs value, consequences and what the team can realistically carry, and a shared language for saying no. A roadmap that changes when the evidence changes, rather than whenever someone has a new idea.
Growth that lasts
Choosing the few measures that show whether the product is creating real value, from a north star down to the leading indicators underneath it, with guardrails that flag unintended harm early. Experiments that answer real questions, and a reporting rhythm that gives leadership the whole story rather than a list of features shipped.
Shaped around your team
Every team starts from a different place, so the format fits the gap rather than the other way round.
Workshops
Half or full days on one skill, such as interviewing, synthesis, competitor analysis or prioritisation.
Team programmes
A few weeks working on your live product, so the team learns by doing the real thing.
Coaching
One to one support for product leads, heads of design and founders.
Embedded support
Working alongside your team for a set period while research, roadmap and reporting get set up properly.
From first conversation to a team that keeps going
A first conversation
About your product, your strategy and targets, and where the team is getting stuck.
A look at how things work today
How research, roadmap decisions and reporting actually happen, what the current metrics reward, and where it all loses touch with the strategy.
A programme shaped around the gaps
Built on your live work rather than made up exercises, so the learning sticks.
A team that keeps doing it
Templates, rituals and habits that stay in place after the training ends.
Twenty years, from the bottom of the ladder up
I’ve sat in most of the seats around a product team, which is why I teach research, roadmaps and reporting as one joined up practice rather than three separate skills.
Designer
Starting at the bottom of the ladder, learning how brands and products are made by making them.
Marketing
Seeing the other side of the product: how people find it, what makes them care, and what the numbers say.
Web developer
A hybrid role bridging design and tech, clearing the bottlenecks that open up when the two don’t speak the same language.
Product design and leadership
Since 2018, leading product and product design from startups to enterprise, including crisis tools adopted by 22 government departments.
Co-founding SIX
I co-founded SIX, Australia’s first platform to bring ethical investing and shareholder activism together, and as chief product officer led the product from its first concept. It was grounded in user research and data from the start, and it taught me to think through every part of a business, from its processes and partners to the people it serves and the targets it has to hit.
Scale amplifies what’s already there
I’ve built products at national scale under crisis conditions, and I’ve seen what happens when speed outruns alignment. The product ships, the numbers look good, and the cost lands on the team and on the people the product was meant to serve. The same practices that make a team fast can make it brittle when nobody is asking why.
That’s why I don’t teach research, roadmaps and measurement as tools for going faster. A product team is a system too, and its roadmap is where the company’s strategy meets what it actually builds. When the questions are good and the why is clear, teams do fewer things better, and the people closest to the customer get listened to. It’s the same question the Coherence Framework asks of a whole organisation, asked of one product team.
Bring it to your team
I work with startups looking for product market fit, growing companies whose teams have scaled faster than their practice, design and product teams inside larger organisations, and purpose-driven organisations building digital products.
Tell me what your team is working on and where it’s getting stuck.