I’ve been in product management for over a decade now. In that time I’ve worked for, with and alongside different organisations across many industries at various stages of maturity. What I have observed is that the ability to develop product in ways which reliably and efficiently produce value to customers and the business has a keen correlation to the size and maturity of the business.
Too small and you lack the resource and processes to produce change which reliably moves the dial; too large and bureaucracy and technical debt will significantly slow your pace of change. I’ve come up with a framework to express this, splitting businesses into 5 (rough) phases of product development. Different types of product managers with varying life and career goals will suit different phases and I have some tips for you to identify where you should be.
The 5 Phases of Product Change Efficiency
‘Efficiency of product change’ is how quickly we deliver change that has a positive impact on customers and the business. Delivering change very quickly isn’t useful if it has a negative or neutral impact, delivering positive change but incredibly slowly leaves you behind your competitors. What every product organisation is shooting for is a product delivery model that reliably produces positive change in the shortest possible time in a way which is repeatable.
So what’s it like in these 5 phases?
‘Hit-and-Miss’
Early-stage startups move fast. They are unencumbered by technical debt and have identified a problem they wish to solve before they’ve even started. Often product change, particularly at the very start, doesn’t involve a product manager, in fact often the product manager, the designer and the engineer are the same person - the founder. If the founder can’t code and design, those roles may be outsourced/performed by freelancers, not full-time employees.
Pace isn’t a problem here, but ensuring change is positive can be. You don’t have money to conduct extensive user research, if you want feedback on your prototype or to run a survey you’re going outside with a clipboard or a tablet and finding people on the street. Your organisation hasn’t invested heavily in analytics packages so you’re making do with your quickly-put-together Google Analytics reports. You can’t afford to fail, though, so you work longer and longer hours and push yourself harder and harder.
You should work here if: You’re early-on in your career and you learn best through doing and experimenting and don’t need a strong product leader to guide you. You love the idea of creating something from scratch and leaving your footprint all over a product.
You should avoid if: Working until 2am answering customer service emails sounds unpalatable - you’ll need to be a jack -of-all-trades here. Also if job-security is crucial, this isn’t going to be for you - early-stage startups fail a lot.
‘Building Best-Practice’
Now we’re looking at startups that have validated their business model and have a bit of cash, either from something like a Series A funding round, or they’re making small profits and able to self-fund. We’re laying down the foundations now to build a business at scale and starting to look more like a ‘proper’ company. There’s a product squad with a PM, engineer/s and a designer in-house.
You’ve got money to conduct proper research, you are implementing robust data analytics tools and have built out your tech stack so code releases are reliable and predictable. The pace with which you release change may slow slightly from the ‘hit-and-miss’ phase, but the confidence you have in each change making a positive impact has significantly increased. Your product also has more users, enabling you to gather enough data to yield statistically significant results quicker and you have the traffic volume to start running multi-variant tests in some places and the cash to bring in tools that’ll make it easier for you to build and measure them.
You should work here if: You want the opportunity to shape the future of an organisation without the lack of security that comes with working in a very early-stage startup.
You should avoid if: you like stability and consistency. During this phase the tools and process you use are going to change and evolve (and you’ll play a key-role in shaping them) and your organisation is going to look very different from when you started very quickly.
‘The Sweet Spot’
The problem with ‘The Sweet Spot’ is you don’t know you’re in it until you’re not. This phase doesn’t mean everything is perfect and ‘The Sweet Spot’ at one organization may be less efficient than ‘building best practice’ at another, but it’s as good as it’s going to get for your organisation, so try to spot it and enjoy it!
Your company has hired senior leaders that bring fresh ideas and ways of working from their previous roles. You’ve got a great product that users love, an engineering team that’s been working on the codebase long enough to have it well-organised and easy to maintain and the technology available to you to really understand what’s going on with your product. You might not move quite as quickly as you used to, but you’re doing so with precision accuracy and it feels like everything you touch turns to gold.
You should work here if: You’re a high-performer that isn’t afraid of lofty targets and wants to be surrounded by excellence, with the best tools and processes available to maximise your own efficiency.
You should avoid if: You want to learn how to build a great product team. You’re joining a place that’s figured out how it wants to work - if you’re someone who adds value to organisations still trying to figure it out, you’re best-off at an earlier-stage startup.
‘No Small Change’
The organisation is getting bigger now and with that comes complexity and bureaucracy. Those 2 or 3 stakeholders you had to manage in ‘The Sweet Spot’ are now 10 or 20. You have the same tools you had before, but they’re starting to become outdated and you have to fight for funding to replace or update them. You still have great investment in your product and don’t need to skip corners in your research and development.
With a bigger business comes more accountability and scrutiny, you have risk and security requirements to satisfy, you can’t move fast and break things because you have a brand reputation to protect and because you’re at a business that successfully scaled, the competition is heating up as others want a slice of your pie. Making changes to the codebase has become more difficult because you’re starting to build up unsustainable levels of technical debt and you start debating whether it’s best to add on top or start building new technology.
Consequently, there’s no such thing as a small, easy change. Everything you do is complex because it has to go through an Enterprise code release process, be signed off by risk, legal and information security departments and you need to get buy-in from all your stakeholders and communicate everything you do to 1000s of people - something as simple as a change to some copy on your site needs to be planned weeks or months in advance.
You should work here if: You’re a great diplomat with excellent ‘soft skills’ and enjoy forming relationships with a diverse range of people in lots of different areas. If you excel at delivering presentations, are extremely well-organised and good at working out what motivates different people you’ll excel here.
You should avoid if: You can’t stand office politics and are obsessed with having full autonomy of your product.
‘Worst of Both Worlds’
Your organisation has been around for a while and it’s no longer the place that innovation in your industry happens. The competition isn’t just heating up, it’s winning. Revenues are either stagnant or shrinking and the pressure from senior executives to deliver is intense.
Because the company can’t increase its revenues, it looks to slash costs. You’re now being asked to deliver more with less. Customer research and user testing is out the window, your engineering team has been made redundant and outsourced, there’s no ongoing budget, every change you want to make has to have a full business case made and estimations done for and then you have to beg, steal and borrow to get the money to make it. Execs want big, shiny things delivered to impress investors and they give you fixed scope with an unmoveable, unreasonable deadline to deliver it by.
You should work here if: You’re a masochist. Seriously, don’t do it.
You should avoid if: You know what’s good for you.
