More grit than glamour, says Intercom's Des Traynor.
In Summary:There’s no one definition of the Product Manager role - it varies from company to company and on the size of the team. Early-stage startups need generalists who are as comfortable chatting to would-be customers as they are analysing engagement metrics or developing wireframes.
As the team grows, Product Managers become more focussed on the Job to be Done (or the problem to be solved) whilst delegating the solution to specialists in the design and engineering teams.
It's important to remember the external-facing aspect to the role. It’s a Product Manager’s job to know if and when their product will be affected by trends like AI,bots or VR.
Actual Product Management is low on glamour and high on nitty gritty: there’s a lot of spreadsheets, Google Docs and Slack channels required to move a product in a specific direction.
An essential guide for Product Managers from AppCues' Julie Chen.
In Summary: Creating a product that succeeds across borders requires getting back to the basics of Product Management.
Without a clearly defined problem, a product can struggle in its local market, even more so on a global scale. Whilst it's common to think mainly about the product when discussing growth, it's worth remembering that the monetisation model may need adjusting for different markets as well.
To fine tune your onboarding for a global user base, cohort analysis is crucial. You need to segment your onboarding steps by different user properties (such as geography and language) and see where users are churning.
Measuring success can also be a challenge. Applying the same metrics to a brand new market as your home market sets unrealistic expectations. The key is to approach every expansion as an experiment and conduct rigorous user testing and research.
Red flags from GoSquared's James Gill.
In Summary: Plenty of features progress from inception for the wrong reasons. Bad features often start from an internal discussion, rather than a genuine customer need, and fail to consider the 'Job To Be Done.'
Even when you’re building something with the best intentions, it’s still easy to execute poorly on an idea by only considering the 'happy path' of the user experience rather than error states and the 'zero data' state.
Without well defined reasons for building the feature, it’s hard to articulate how it could be valuable to your customers. Good features come from focusing on the customer and their problem. It can be helpful (like Amazon) to write a short Press Release to outline why customers will benefit from the feature, before building anything.