I had a unique opportunity of joining a sizable organization that was proving itself as a market success with their early products, but was struggling to create valuable new ones in a timely manner in order to to maintain an edge above competitors. At the time I joined, products both large and small were being developed in a waterfall manner with little insight into progress from the rest of the organization, and all were far behind schedule from the point of view of the stakeholders. Other major replatforming projects were also ongoing, and the justification for these were poorly understood outside of the engineering team.

I led the implementation of new processes related to product planning and execution in order to better connect business needs with development resources. These processes led to a focus on products which created value for our customers, faster development times, iterative development that included customer feedback, and accurate estimations for both short as well as long term projects.

Here is my advice on how others can be successful in a situation like this, based on what went well, and what I would have done differently.

Identifying Challenges

Before simply diving in and making changes, you will need to analyze the current situation and understand what value stakeholders are expecting to be delivered that they are not seeing from the product and engineering teams. Similarly, understanding the challenges that the engineers and product members themselves face can help guide the changes that will need to be made. In both situations, you will need to gather both qualitative as well as quantitative information. Your goal may be to improve the the quality of products being launched, increase the efficiency of development, have a team that can better respond to changing market needs, or possibly all three. Finding the gaps and weaknesses in the current situation will help you develop a means of achieving these goals.

Developing a Plan

Choosing a set of processes that allows for the goals to be achieved is very situational, as there are benefits as well as trade offs to all of your options. For example, reading lots of blog posts might lead you to think that agile methods are the only ways to build software, but the truth is that there are many benefits from other methodologies in certain situations. Similarly, how you work with a team of product managers in defining and roadmapping their projects depends greatly on their experience and technical expertise. Just like with a product itself, you need to apply both research as well as user feedback in order to define an actionable plan.

Proposing New Processes and Gaining Buy In

In order to be successful with any process changes, you need to have buy in and support from everyone involved, from the stakeholders to the product managers to the engineers. Making sure each person understands the value they will gain is incredibly important, or else support and uptake will be limited.

Painful First Sprints

No matter how you prepare, you can not expect the first sprint to be incredibly smooth. Discussions will be brought up on whether arbitrary points or time estimates are more appropriate. The sprint meeting will take twice as long as you expect. You will learn about hidden work-in-progress that was never brought up before. To get past these hurdles and towards more stable sprints, you need to ensure that these early meetings and sprints are valuable for everyone involved, or they will simply give up on trying. For product owners, this means getting their goals prioritized and worked on in a much shorter time than they are used to. For engineers, they can be opportunities to reduce outside distractions and allow focus, even if the estimates themselves are significantly off mark.

Optimizing the Processes

Product development processes are never "set it and forget it." The team will grow, the business needs will change, and bottlenecks will arise. Like with a product itself, the product development processes needs to be iterated and improved upon based on both qualitative as well as quantitative information.

In order to improve how the products themselves are being built, you need to understand what metrics are valuable to improve, and what the inputs are that cause these metrics to change.  If you want to reduce work-in-progress, you may need to look at where the bottlenecks in your sprint workflow are. If the products being built are failing to gain traction in the market, you might need to update how you do user research, or possibly find ways to beta test MVP's before fully building the products. 

Process changes can also be painful. There could be new things to learn, new checkboxes to remember to check, or everyone's favorite; new meetings. What I have found is that in order to be successful with process changes, everyone affected needs to see and feel the benefits that they bring. Implementing assignments for code reviews means more work for people, but it also means that everyone's own projects will get out the door faster if everyone does their part. Meetings for the sake of meetings will not benefit anyone, and will only cause pain and tension. You have to pitch and sell these processes the same way you would with your products, and show that they bring value to everyone involved.

Planning for Growth

If you are successful at developing products that provide increasing value to your customers, you will need to grow your capacity to produce. Hiring takes time and energy, and discovering too late that you need more people will cause a severe bottleneck in your development pace as you put extra time into growth. Being clear on the responsibilities that new team members will own or take over will help narrow your search to the right candidates, and ensure that they can have an immediate impact when they join.

Looking Back One Year On

Since these changes went into place, both the product as well as engineering teams have nearly doubled in size. For the past two quarters, nearly all major product development goals have been met. The original processes I rolled out are still largely in place, but just as we do with our products themselves, we iterate and improve our processes to create even more value for the organization.