The organizations that get this right don't just hire someone and hope for the best. They invest in four things, in order: defining how the function operates, hiring people with the right disposition, developing those people intentionally, and building enough organizational trust that the practice sustains itself after the person who built it moves on.
Define the Operating Model
Before you hire anyone, the organization needs to agree on what product management actually means here. Not in theory. In practice. What decisions does the PM own? What decisions require consensus? How does the PM relate to engineering, to design, to the business? Where does their authority start and end?
Most organizations skip this step. They hire a PM, hand them a backlog, and wonder why they're not "being strategic." The PM wasn't set up to be strategic. They were set up to be a project manager with a different title.
At an Industrial IoT company, I was the first product manager ever hired. There was no definition of the role, no process for how product decisions got made, and no shared understanding of what the function was for. Before I touched the backlog, I spent time understanding how decisions were actually being made, where the friction was, and what the engineering and sales teams needed from a product function that they weren't getting.
That assessment became the foundation for the operating model. Not a document nobody reads. A working agreement about who owns what, how priorities get set, and where product management adds value that nobody else in the organization can.
Hire for Character
Product management is a role where curiosity, judgment, and the ability to navigate ambiguity matter more than any specific tool or certification. You can teach someone Jira. You can't teach them to sit with uncertainty and still make progress.
When I've built teams, I've consistently hired for disposition over credentials. People who ask good questions. People who default to listening before prescribing. People who can earn trust across functions because they're genuinely interested in what other teams are dealing with.
At a telecom billing platform company, I was responsible for hiring and building a 12-person product team from scratch, including six offshore roles. For every hire, I spent time evaluating personality traits and willingness to learn rather than filtering for tool proficiency or industry-specific experience.
The result was a team that became the organizational focal point for how work got done. They earned trust because they were curious, reliable, and willing to learn. That trust gave them influence that no job description could have granted.
Develop the People
Hiring the right people is the beginning, not the end. A product practice that runs on the instincts of the person who built it is fragile. The investment is in developing the team's judgment, not just their output.
This means regular, intentional 1:1 time. Not status updates. Actual mentoring. Working through real situations together, asking questions that help them develop their own framework for making decisions. Over time, the team stops needing you to make the call and starts making calls you would have made.
When I joined a digital media company at the onset of the pandemic, I inherited a product team and immediately had to hire and onboard new members in a fully remote environment. Weekly 1:1s became the backbone. Not just work conversations. Real mentoring about how to navigate ambiguity, how to push back constructively, how to build credibility in a new organization.
For new hires, I built a structured onboarding process and paired each person with a buddy for their first 90 days. The result was a team that maintained high morale through a period of extreme uncertainty and continued to deliver on time. They trusted each other because the relationships were built intentionally, not left to chance.
Make It Outlast You
The real test of a product practice isn't whether it works while the person who built it is there. It's whether it holds after they leave. This is the difference between building a team around yourself and building a capability the organization owns.
This means working through existing leaders rather than around them. Coaching the managers, not just the individual contributors. Embedding the practices into the organization's rhythms so they feel like how things work here, not like something an outside consultant introduced.
At a global retailer, the engagement was explicitly about establishing a product management function that the organization could sustain independently. I worked through an advocate leader, coaching managers on prioritization frameworks, building data-driven decision-making processes, and reducing the reliance on custom work that was consuming capacity.
The measure wasn't whether things worked while I was there. It was whether the team could articulate the operating model, defend their prioritization decisions, and run the cadences without prompting. A 52% improvement in team efficiency was the metric. The real outcome was a function that the organization understood, trusted, and could continue to develop on its own.
Building a product practice isn't about importing a framework. It's about listening to what's broken, hiring people who care, developing their judgment, and then getting out of the way.
I've done this five times across IoT, telecom, media, retail, and enterprise platforms. The industries are different. The organizational dynamics are different. But the pattern holds: define, hire, develop, sustain. Skip a stage and the practice collapses back into project management within a year.
This work has also shaped how I approach mentoring more broadly. Over 100 emerging product leaders through Pathrise, MentorCruise, and inside client organizations. The questions are the same whether you're standing up a practice at an enterprise or helping an individual figure out how to lead without positional authority.