10 Scaling Tips for Product People [Roman Pichler]
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.
Your Scrum Master should 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.
6 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—instead of component teams who look after an architecture building block like the front end or persistence layer. Feature teams have fewer inter-team dependencies compared to component teams and reduce the risk of sub-optimisation, optimising individual architecture building blocks at the cost of the overall product performance. They do require, however, that shared standards are in place to avoid undesirable variations and code duplication: You typically don’t want that every feature team uses its own UI design flavour and writes code that’s already been developed.
As you add feature teams to the development effort—hopefully by growing organically—you also have to consider the impact on your workload. My experience suggests that a single product person is usually not able to work with more than three agile development teams. You will therefore have to consider involving additional product people who can own features and guide the feature teams. I call these individuals Feature Owners. The image below shows how the role can be applied. For more information, please refer to my article “Scaling the Product Owner Role”.
7 Start with One Site and Distribute Work in a Stepwise Fashion (If Necessary)
While it can be hard to bring the right people together, few things in software development are more counterproductive than starting a new product development effort with a dispersed team—a team whose members work in different places, for example, London, Boston, and Bangalore.
As a rule of thumb, the more uncertainty, change, and innovation are present, the more important it is that everyone involved in the development effort is co-located, including the person in charge of the product. This allows you to build rapport, establish an effective collaboration, and agree on shared standards, for example, how to collaboratively refine product backlog items and have effective sprint reviews.
Therefore, 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.
8 Consider Unbundling Features and Creating Product Variants
Growth is a funny thing. While it’s is a reason to celebrate—the product has finally entered the growth stage and become successful—we now have to cope with an increasingly large and heterogenous target group, more diverse needs, more features, and more development teams. But it doesn’t have to be this way.
Remember when Facebook unbundled Messenger in 2014 and launched it as a standalone app? Unbundling is a great technique to avoid that a successful product becomes bigger and bigger, more and more heterogeneous, and requires an ever-increasing amount of people to manage and develop it. Instead, you create a new, specialised product with its own dedicated product person and development team.
Product variants do a similar job: But rather than spinning off one or more features, you create a version that is tailored to a specific target group. Take, for instance, Microsoft’s diagramming tool, Visio, which the company offers the variants Visio Standard and Visio Professional. Each variant can be developed by a separate team and have its own product person who looks after it.
9 Take Advantage of a Platform
A platform bundles shared assets, for example, shared front end or back end components or common services like persistence, logging, and security, and it standardises the way they are used. Using a platform offers two benefits in a scaling context: First, it encourages reuse and avoids the need that each team develops their own, say, logging service. Secondly, it creates and enforces standards across different features and teams, such as a common user interface design.
When creating a platform, you have two options: You can either employ collective ownership and ask the different feature teams to jointly look after and advance the platform. Alternatively, you can manage the platform as a product in its own right with a dedicated platform owner and team. (Note that a platform owner usually requires in-depth technical skills, as the individual is usually required to talk to the feature teams about new interfaces and changes to existing ones.)
My recommendation is to start with the collective ownership. This maximises the chances that the platform does a great job at supporting the end-user facing functionality and it minimises the risk of building an ambitious platform that is difficult to use and integrate with. If and when the platform has grown to big to be collectively maintained and advanced, consider employing a dedicated product person and development team.
10 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, as “adding people to a late development effort makes it later” (Brook’s Law).
Nevertheless, I have worked with more than one organisation that thought this law would not apply to it and added more people in order to accelerate a project that was in danger of missing its target date, only to find out that this caused additional problems and delayed the project even further. Therefore, 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.
The post 10 Scaling Tips for Product People appeared first on Roman Pichler.
Source: Roman Pichler https://www.romanpichler.com/blog/10-scaling-tips-for-product-people/
Post a Comment