10 Scaling Tips for Product People
Managing a growing product can be as rewarding as challenging: Involving more people and teams and scaling up is hardly ever easy. This article shares 10 practical tips to help you effectively scale as the person in charge of a product.
1 Involve the Right People
A small group of qualified individuals who have the right skills and motivation can be more productive than many individuals who lack the necessary expertise and act out of obligation. This is true for product people and development team members alike in my experience. Therefore, make an effort to involve the right individuals. This will allow you to move faster, stay small for longer, and be more adaptive.
While this probably sounds like common sense, I’ve seen more than one organisation trying to get more done by throwing people at a product. One company I worked with, for example, assigned developers who had worked on enterprise systems using an ancient programming language to develop a brand-new, embedded product with the latest technologies. No wonder that the individuals struggled and the product suffered.
Your Scrum Mastershould be able to help you find the right people and address any impediments that might prevent you from doing so — for example, being assigned individuals without considering their skills and motivation.
2 Don’t Scale Prematurely
I once worked on a new product development effort where more than one hundred developers in three locations had been allocated right from the start of the project. While initially, there wasn’t enough work to keep so many people busy, the development teams didn’t want to twiddle their thumbs and started writing software. This led to a bloated, over-complicated code base and a product that was difficult to adapt and expensive to maintain.
Rather than 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 that may be required in order to move into the growth stage.
3 Build an MVP
Another great way to reduce the need to scale is launching a minimum viable product (MVP). Such a product typically requires less time and fewer people to develop than a more ambitious, feature-rich one. What’s more, it can be easier adapted to the market response in order to achieve product-market fit.
How minimal your product can be depends on its market. For example, in the case of the original iPhone, Apple created a new market and could therefore offer a comparatively minimalistic product. Contrast this with the Apple Watch, which entered an existing market and directly competed with established offerings from companies like Samsung, Garmin, and Fitbit.
4 Help the Development Team Become Self-sufficient
As your product grows, your workload usually increases too: Addressing a growing number of users requires more effort to understand their often heterogeneous needs and decide how to best address them. 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, for instance, by involving team members in user research (as part of the product discovery work) and exposing them to direct user feedback on early product increments. This will allow the team members to own the solution and make the right UX and technology decisions, increase people’s motivation, lay the foundations for adding more teams, and free you from having to create detail-rich user stories and still answer lots of questions during the sprint.
5 Grow Organically
Back in 1968, Melvin Conway observed “that there is a very close relationship between the structure of a system and the structure of the organization which designed it.” This means that if you start with, say, three development teams, the software architecture of your product will probably consist of three major subsystems — no matter if this architecture supports the desired user experience and features.
To avoid this risk, start with one product 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. This approach is also called growing organically, as it mimics cell division in living beings.
In addition to escaping Conway’s Law stated above, growing organically offers two more benefits: It evenly spreads the effort of bringing the new people up to speed instead of having one unproductive development team with all the newbies, and it allows you to measure the impact of adding more people on productivity and infrastructure.
The latter might seem rather dull, but I once worked with an organisation that moved up from three to eight development teams in one go in order to accelerate development. Unfortunately, nobody had anticipated that the infrastructure was not able to cope with the increased network traffic caused by the new teams. Consequently, checking-in and checking-out code suddenly took minutes instead of seconds, which meant that the development speed was significantly reduced until the required upgrade work was finally carried out.
Read On …
To read the rest of this article and access the remaining tips, please head over to my website: https://www.romanpichler.com/blog/10-scaling-tips-for-product-people/
Learn More
To learn more about scaling, attend my Product Owner Masterclass and read my book Strategize.
Source: https://www.romanpichler.com/blog/10-scaling-tips-for-product-people/
This article was first published on roman pichler.com. Subscribe to my blog to never miss an article.
