What I expect from a small product team
I build with AI almost every day, both on my own projects and in my product work. That has made me think more about how a small product team works. When we can try an idea sooner, what do we do with the time we save?
I lead a product and also build my own app, Fin Cinema. From both perspectives, I am interested in the path from an initial idea to something that helps people in their daily lives. For me, that involves four tasks: understand, decide, build, and learn.
Making room for product work
In a small team, very different tasks compete for the same time. Customers need support, bugs need fixing, and technical partners need coordination. Every task has a good reason behind it. Yet a busy week can end without a clear answer to what the team has learned about its customers.
That is why building a product team also means taking an honest look at its capacity. Who talks to customers regularly? Who looks at what happens after a release? How much time is actually left for that work after support, operations, and coordination?
I want to be able to answer those questions before committing to additional product goals. Learning from customers needs a regular place in the team's work.
A goal we can check
Onboarding makes this tangible. “Improve onboarding” leaves a lot open. What first useful result are people looking for? Where can they move forward on their own? At what point do they need an explanation?
A more specific goal would be: new customers reach a clearly defined first useful result independently. We can then observe how many succeed, how long it takes, and where support is still needed. We need to look at individual successes in relation to everyone who started onboarding.
This also helps us decide what to build. We might need a different flow, clearer language, or a better default. The problem should guide the choice of solution. After making the change, we check whether our assumption held up.
Shared understanding, clear responsibility
For this work, I want product, design, and engineering to work closely together. All three perspectives need direct access to the customer problem. The people designing and implementing a solution should know the observations behind it and be able to ask their own questions.
Each perspective also needs depth. The team must be able to set well-founded priorities, design understandable flows, and put changes into production reliably. Responsibility for that work should be clear. Knowledge, reviews, and cover need to be organised so that the team can keep working when someone is away.
How I want to use AI
For me, AI is a practical tool in this collaboration. A prototype lets us explore an idea together and test assumptions earlier. I can build something myself, gather feedback, and develop it further.
To judge whether we save time, I want to look at the whole process, including review, rework, and operations. Where we do gain time, I want to invest some of it deliberately in understanding customers and checking our decisions.
My ambition is a team that can explain why it is building something, deliver it reliably, and then assess whether it helped. Creating the conditions for that is part of what product leadership means to me.