How to Scale as a Person in Charge of a Product?
Managing a growing product can be as rewarding as challenging. Involving more people and teams and scaling up is hardly ever easy.
The article shared on Romanpichler.com describes the essential tips to help effectively scale as the person in charge of a product. Here’re the brief bullets from the article:
Involve appropriate people
It’s not a secret that a small group of qualified individuals with the right skills and motivation can be more productive than people who lack the necessary expertise and act out of obligation. Try to involve the right individuals to move faster and be more adaptive.
Do not scale prematurely
Instead of scaling prematurely, stay as small as you possibly can until you are getting close to reaching product-market fit. This allows you to quickly respond to market feedback, experiment with new ideas, and make any architecture and technology changes.
Create a minimum viable product
MVP (minimum viable product) is another great way to reduce the need to scale. This product typically requires less time and fewer people to develop than a more ambitious, feature-rich one.
Help developers become self-sufficient
As your product grows, your workload usually increases too. If you have a development team that still needs to be spoon-fed with detailed requirements at this stage, then your workload is likely to become overwhelming. To mitigate this risk, help the development team learn about the users and understand their needs as early as possible.
Grow organically
Begin with one person in charge of the product, one development team, and one Scrum Master. Once you’ve validated key UX and technology risks, scale by asking the team to split up. Then add more people to the newly formed teams.
Employ feature owners and feature teams
As you add more people to the development effort, consider working with feature teams—teams that implement functionality end-to-end.
Start with one site
Start a new product development effort with one team at one site. Once you’ve addressed the key UX and technology risks, consider spreading the work to other sites in a stepwise fashion if that’s required. This allows you to find out how you have to evolve your practices to succeed with the distributed setup, including collaborative product strategy review and product backlog refinement sessions held via videoconferences.
Never scale late in the game
Scaling successfully requires careful forethought and preparation. It should never be an emergency measure to save a development effort that is in trouble. Consider alternative options to save a late project like partially providing or removing features and postponing the release date. Scaling should not be an emergency measure.