You’ve just accepted a job offer – to introduce a product management function into a company. What can you expect? Where do you start? And how do you bring everyone in the organisation with you in the most inclusive and respectful ways possible? Here’s my experience of doing just that.
Firstly, not having dedicated product roles in a software development business might seem alien. However, in my experience, it’s not uncommon. In my last three organisations, there wasn’t a dedicated product manager when I joined, and I was hired by my last two companies to specifically introduce a product role.
In my previous role, I was asked to set up a product owner function where previously the scope of work had been defined by account managers taking briefs from clients. In my current role, I was tasked with taking over product strategy from two technical company founders who, by their own admission, were operating on ‘gut’ decisions.
In both of these roles, I’ve observed a lot of common elements, primarily around the introduction of product thinking into decision-making processes.
What to Expect
If you find yourself tasked with introducing product roles into a business, here are a few obstacles that you might expect:-
Lack of Understanding of Product Roles
This is entirely predictable, but it’s still worth mentioning that you may encounter uncertainty about what product people do. I’ve found that people expect product managers to be focused on logistics and the delivery of items through the development pipeline – more of a “user story shepherd” than anything else. They’re surprised when someone is focused more on questioning, measuring, and testing to identify value.
Resistance to the Autonomy That Comes With the Role
Once the penny drops that the role of product owners and product managers is not simply to work through the list of things that other people want to develop, but rather to guide the strategy of a product or area, there can be resistance from those who previously would have expected to make product decisions. When I was establishing a product function in an agency I encountered resistance from some of the account managers and account directors who managed the client programmes. They had previously been responsible for making decisions about each bespoke development and found it very challenging to defer to my team on product decisions. It led to a lot of friction.
Perhaps the greatest value-add that product owners and managers can provide is to facilitate communication between different contributors and stakeholders. There will likely be communication challenges before the product role is established, most commonly between development and “business” roles such as sales or account owners. In one project I found huge tension between development and an account team about the scope of work because of an optimistic estimate from developers acting under pressure with scant information. This is a common problem when roles with widely differing agendas interact without a specialist to handle any necessary mediation.
An Unrealistic Backlog
I’ve found that, as a new product person, I can inherit a backlog of work with unrealistic expectations on its completion. It’s much easier to write ideas down and take on feature requests than it is to deliver them, and some product backlogs are simply a huge list of every idea and feature request that people inside and outside the business have ever asked for.
I’ve heard similar stories from other product people – I recall that product manager at a recent ProductTank meeting described how they had inherited an enormous and unrealistic backlog of work when they moved to a new team. Before starting, they were under pressure to deliver many months worth of work, totally undermining the value they could otherwise have added in helping to guide the product strategy.
A Desire to be Better
Despite resistance, you can expect a genuine desire to improve the way that things are done when you introduce product management into a company. That the role has been created shows a desire to improve, even though it may come with a lack of understanding about exactly how this improvement can be achieved.
Add Value Quickly
When faced with such challenges in the early stages of a new role, it’s critical to quickly demonstrate the value that a product manager can bring. This not only justifies your remit but also shows the potential value of other individuals and roles that you could add over time if you build out the function.
I’ve found that the following are useful to introduce early:-
Speak to Customers and Users About Value
Speaking to customers as early as possible is crucial in showing how important direct customer access is to your role. I’ve found it a useful strategy to have early discussions with customers about how they can be involved in ongoing product development. Explaining the need to work with them to understand their problems, rather than simply fielding their feature requests, also helps to embed this principle among your colleagues, who may be used to a more traditional feature request-driven approach.
Capture and Present Some Early User Insights
Nothing speaks of the value of user-centred thinking like presenting findings from the existing user base after just a few days. Whether it’s unearthing previously unidentified frustrations with the software, or presenting a well-structured analysis of the target audience or market, creating some rapid and valid insights can quickly build credibility for your product role.
On joining my current company I worked with customers quickly to build some personas that represented the user base. This simple process helped everyone to recognise a disparity between some of the product features and the needs of the target market, and provided an excellent platform for building a strategy to simplify the user experience. If you are struggling for where to start – this excellent reference of product prioritisation techniques may provide some inspiration.
Be Realistic About Development Timescales
Forecasting may well be non-existent without a product role, as estimation can suffer the most when there are communication issues across roles (I wrote more about this in my post – Delivering Estimates And The 5 Stages Of ‘Good Grief’). By providing some realistic development timescales on existing work in the backlog won’t necessarily make you popular, but it will garner respect for providing some honesty to help make more realistic business decisions.
Asserting yourself early with high-value activities in this way is a great way to both justify your introduction to any doubters, but also to shake off any mistaken preconceptions about your role. It means you can demonstrate your intention and ability to decide for yourself on how you will deliver value from your role.
Play the Long Game
When starting in a new company in a relatively senior role there is a temptation to introduce wholesale changes wherever you see challenges. Even though I’ve identified some quick wins above, I’ve found that it’s also important to remember that introducing change is a strategic process. It’s important to tread gently and build over time.
Don’t be too Critical
Being openly and widely critical won’t engender positivity about your role. Respect for the people you work with and the decisions they have made in the past is important. In the early stages of any product or programme development, decisions can be heavily influenced by the demands of strong customers or partners who are needed for early business success.
I’ve introduced product management at the point where the company has had the luxury of having established customers that allow it to invest in more strategic product thinking. You can, of course, challenge existing thinking as you look to the future, but being critical of decisions that allowed the company to reach that point would be unfair and disrespectful.
Tactically Introduce Changes as the Need Arises
Some changes are better introduced in reaction to a problem rather than by driving them through and risking push-back. If your new colleagues can see the value you introduce to solving their problems by using your knowledge and experience they’ll be generally more receptive than if you try to introduce changes when there isn’t a burning need. In my current role, I found the lack of a solid Wiki capability for documenting and sharing my research findings was very frustrating. I held off and observed whether others in the business had similar issues. When I saw that the development team was struggling to share information around a complex architectural development, I set up a trial of Confluence to support the development. This soon spread across to other roles and within a month we’d trialled and rolled out to everyone in the company.
Incrementally Reduce the Product Backlog
Rather than aggressively deleting the entire backlog (or worse still trying to thrash through it before moving on), try to tackle it incrementally, one high-level item at a time. For each item try to identify and speak to the source, being clear that you plan to separate what is contractually promised or committed from what is just wanted. Shift the non-essential items into an aspirational “ideas” backlog one at a time.
If challenged you can promise to bring these back in on a priority basis, but using your own prioritisation techniques rather than the opinion-based processes that created the backlog in the first place. The high-value items will soon resurface from your research work while the vanity pieces will be justifiably mothballed.
Demonstrate Value to Build out
A common element to the companies I’ve worked in recently was that in-house skills were limited to development/test, with no other specialisation. When introducing a product management role to a company that doesn’t have a clear expectation about how that role will deliver value, it’s often the case that there’s also no understanding of other complementary roles, such as UX research and interaction design. Learning just enough of these skills yourself to allow you to demonstrate the benefits that they can bring comes across is a more positive means of justifying further hires than a focus on a deficit of capability.
Taking a strategic and considerate approach rather than making wholesale changes is important to get buy-in from others. It helps to ensure that others come on the journey with you.
Introducing product management roles into a company has many challenges, and if you are prone to self-doubt then the spectre of imposter syndrome can creep in. The one critical takeaway I’ve learned from my experience is that the key to success is to stay confident in yourself and believe in what you’re trying to do.
It’s important to use approaches you can justify and be confident in. There will be times when your approach may yield outcomes that go against conventional company wisdom (such as “we always give the customer what they ask for”). There may be others where the right approach isn’t clear and you will have to rely on experimentation to find it. As long as you maintain a focus on techniques that provide the evidence to justify and support your decisions, then there’s no reason to doubt yourself.
If you find yourself taking on this challenge, then I hope some of the learnings here are beneficial. If you are already well along the path to introducing a product management role in your company, my only additional advice is to look back occasionally and remind yourself of what it was like when you started. Even in a short space of time, you should be able to see what a positive difference you have made. If you haven’t established a product function in an organisation before and are lucky enough to be presented with the opportunity to then grasp it with both hands. I’ve found it to be a hugely rewarding challenge and one that presents a level of freedom and autonomy that few other product roles can offer.