Lessons on building a Product function

It can be hard to win over hearts and minds on the value of the PM role. Here's an example of how we did it

---

I was working in a division of a large company with no Product team. They needed to overhaul their technical infrastructure to stay competitive in the market. Previous attempts to do this hadn’t delivered the solution that would really drive desired outcomes. 

A small group of us were asked to work on it and we took this opportunity to build out a Product function. Here’s what went well, and where we could’ve done better.

What went well

We understood the problem space

We engaged with the users immediately. This revealed that the system was unintuitive and the data model was not aligned with their ways of working - so they weren’t using it.

We dug into the user journey and worked with engineers to gain a better understanding of the legacy data model. We rolled out an enhanced version of the platform 3 months later - with a new, fit for purpose UI and reorganised data model in the back end.

We empathised with engineers

We built relationships with the engineers we were working with, and took the time to understand their frustrations and brainstorm ideas. It was clear where we could make immediate, positive impact in a way that helped them focus. For example, we started translating vague user 'requirements' into clear user stories and wireframes, so more of their time was spent coding. 

By helping the engineering community, we not only positively impacted organisational efficiency, we also nurtured advocates that vouched for us as value-add team players.

We explained the purpose of our function, within the context of our organisation

We outlined what we were responsible for and what we would contribute to, and presented this anywhere we could - for example in divisional town halls or team meetings of other teams. This not only helped raise our profile and start conversations about opportunities, but it also carved out a non-threatening remit for us to operate in.

We shared successes widely

We shared a visual ‘before and after’ of the platform widely, and coupled with testimonials from users, it was a clear sell of our skills and value. It drove home the message that partnership between Product & Engineering was integral to delivering valuable outcomes that met both user and business needs.

Coulda, Shoulda, Woulda

We could have built a community of practice

There were other nascent Product teams in the company, and there could have been opportunities to collaborate, share experiences and build a consistent vision of the Product craft for the company. One way we could have done this was through setting up a Community of Practice where Product people could ask questions, share ideas and work on central strategy together.

We should have looked outside the organisation

There is a wealth of knowledge on forums such as LinkedIn, Substack & Twitter that I now engage with regularly to improve my craft. Engaging with Product outside of the company as a whole, could have led us to even greater outcomes and insights.

We should have tracked our commercial impact

Product’s contributions enabled the company to retain existing business as well as win new clients. We didn’t track these commercials, which would have told an undeniable story of impact. Having these numbers to hand would drive visibility and ensure that Product got brought to the table on other projects going forward.

In summary

Setting up a Product practice is hard. It's a new role to many people, but the problems are familiar to all - so build relationships based on how you can contribute to solutions. Try to balance out best practice with organisational specifics, and lean on the community for advice on how to approach this. Find ways to add value quickly, and don't get overly conceptual - tell your story with data that resonates.

Experienced something similar? We’d love to hear your own takeaways in the comments.