Building a product function from zero: what to put in place first

The short version

• Start by listening to customers, before you write a process.
• Make ownership and decision rights explicit.
• Keep the cadence light, measure early, and let structure grow only when it earns its place.

At Maqsam I pioneered the Product Management department, establishing the foundational practices and growing the team from inception. Starting a product function is a different job from running one. There is no inherited playbook to follow, so every habit you introduce becomes the culture. Here is what I'd put in place first.

Begin with customer conversations

Before any framework, I'd talk to customers. At Maqsam, discovery calls led to customer-focused product improvements and lower customer turnover. It is a practice worth building into any new function from the first week.

A few habits make these calls useful:

• Ask about situations and workarounds, not features. "Tell me about the last time this went wrong" beats "Would you use X?"
• Listen for the effort customers already spend to solve the problem themselves.
• Record patterns, not just quotes, and share the raw words with engineers and designers.

Make ownership explicit

Early product functions lose time to unclear decisions more than to anything else. I write down, on one page, who decides what: product owns the what and the why, engineering owns the how, and anything in between has a named person. When two people disagree, it is clear who decides, and everyone knows they can disagree openly first.

Choose a cadence you will keep

I introduced Agile ways of working, which improved the efficiency of the product development lifecycle and team productivity. The lesson I took from it is to start with the smallest set of rituals that produce decisions:

• A weekly planning conversation.
• A regular demo so progress is visible.
• A short retrospective so the process improves.
• Quarterly priorities that everyone can repeat.

If a ritual doesn't change a decision, drop it.

Measure before you optimize

Instrument the product early, even crudely. At Maqsam, analytics helped improve platform reliability and reduce payment failures, which in turn improved customer satisfaction and loyalty. Metrics don't need to be sophisticated. What matters is that they exist before the debates start.

Choose a handful: reliability, activation, engagement, and one that reflects customer value. Review them regularly, and use them to decide, not to decorate a slide.

Write down how you decide

Prioritization is where a new function either earns trust or loses it. I use a simple frame of impact, effort and confidence, with explicit room for strategic bets. The scoring is not the point. The point is that people can see the reasoning, challenge it, and learn how decisions are made. (If you'd like to try it, the roadmap game on the home page is a small version of the same exercise.)

Grow the team for judgment

Process can be taught; judgment takes longer. When the team grows, I look for curiosity, clear thinking and comfort with ambiguity, and then teach the practices by doing the work together rather than handing over a document.

Avoid process theater

A new function is tempted to prove itself with templates, ceremonies and dashboards. Resist it. Customers, engineers and the leadership team should feel that product work makes decisions faster and better. If it makes them slower, something has gone wrong, however well-organized it looks.