How to Manage the “Need for Speed” Without Sacrificing Quality

The pace of innovation today is faster than it has ever been. Customers are much more active and vocal thanks to social and mobile channels, and the conditions are such that time-to-market matters. Married with that is increasing adoption of agile and lean principles that have aligned the software development processes to allow a much faster time-to-market.

This speed, however, does not come without a cost. Within the last several years, we have seen an increase in recognition of concepts like technical debt. If you are not already familiar, Wikipedia defines technical debt as “a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.”

And therein lies the trade-off between the need to move fast and reduce time-to-market and the quality of the design and engineering behind the product. The product leader as well the product team must embrace the fact that this is the reality of today’s market and establish ways to manage this well. So how do we do it? Here are some tactics….

1. Clear Goals and Rules of the Game

All markets are not created equal and therefore all product management decisions cannot be governed by the same rules. So look at your market and your strategy and define what’s important. In a highly competitive market, quality might play a bigger role than the one where you are the disruptor or where you have a greater lead or monopoly.

Our CTO, Jonathan Rivers, recently spoke about the fact that focusing on 99% production uptime might not be the right thing for an organization. On the face of it, this seems like a bad idea; however, if you think about it, the goal of 99% production uptime requires a thorough QA and very efficient processes. Not all products need that, and if you reduce that goal, you start to gain time-to-market.

In order to be able to do this, you have to start with your business goals. These business goals then should be translated into rules or guidelines for the team. For example: what is an acceptable defect rate?  What kind of bugs are OK and what are not? How many rounds of customer validation are needed ? and so on.

These help your team align towards the same goals and guidelines, so plan with these in mind.

2. Culture and Mindset

Not everything can be described in terms of rule or guidelines. The team needs to understand the intent behind them and not be limited to what is explicitly described.

Facebook has these wonderful posters with guidelines like “Move fast, break things”, “Code resolves conflict” , “What would you do if you weren’t afraid”. These posters are put around the office and Facebook truly believes in them. It is a part of their DNA.

In the case of Facebook, you can imagine they value creativity and empower their employees a lot. They have systems in place to safeguard the company and limit the associated risk, but they care about speed and have made that a part of their core culture.

This is really powerful as it allows the team to make conscious decisions about the trade-offs we discussed before. They not only understand the specific goals, but also understand how to approach new ideas and challenges. This also means that they have a reference point when making decisions. Going back to Facebook posters, one of my favorite ones is “Code resolves conflict”. So the next time the team has differing points of view – which good teams will have frequently – someone will point to that poster and get the team to build stuff instead of arguing.

At 3Pillar we build 100s of products for our clients and as one can imagine, there is a lot of room for teams to be misaligned and get siloed. To unify and drive the focus towards the same goals, we defined something we call the Product Mindset. It essentially provides a way of thinking about and approaching product development to our teams. It talks about 3 simple principles:

• Build for Outcomes
• Minimize time to value
• Excel at Change

These principles comes into play in a lot of product decisions. During roadmapping it informs priority and release planning, during estimation it pushes the team to not over or under scope the features and when things change they don’t see it as scope creep, but as a valuable process. All this helps the teams move faster because they have a framework that unifies them and speeds up decision making.

3. Processes and Tools

The previous two points are about how we think about stuff. We also need to define how we actually do things. Referring back to the Facebook poster that says “Move fast, break things”, it sounds good – but what happens if you break things? Facebook has several processes to manage these risks. For example, when a new code is deployed, it is only deployed to a small subset of their customer base. So if something was to go wrong, it only impacts a smaller subset and reversing the change or adding a fix is also much easier.

So you need processes that govern how the team functions, that act as safeguards to minimize the risk to the business and enable you to respond quickly when things do go wrong.

One area to call out here is Prioritization. If the team has a clear set of priorities that align to the business goals, they can remain very focused. This means that they might be cutting features and that is OK.  More features does not equate to a better quality product. Having a strong prioritization process is a strong foundational step to get started with improving your process.

Tied closely to prioritization is the communication process. What are the meeting rituals – weekly planning, daily standups, regular demos and retros? How does ad-hoc communication happen – just verbally if it’s a co-located team, or over chat or Slack and so on?

At 3Pillar, we have built and refined our agile process that applies our Product Mindset in a distributed team environment. We call this Adaptive Product Lifecycle Management. You can see our process here.

In addition to the processes, the product design and development tools have improved as well. Take for example the user experience design process. We used tools that were siloed and required manual effort to move between different stages of the process. One such tool was Adobe Photoshop. About 4 years back, we switched from Photoshop to Sketch. Sketch does not have everything that Photoshop does; however, for our product design purposes, it has helped immensely. It has built-in capabilities to create pattern libraries, integration into prototyping tools like Invision, and the ability to deliver design specs to engineers using plugins like Zeplin. This has streamlined the process and allowed us to move much faster, which means our designers can focus more on solving complex problems.

One more area of opportunity that I would like to call out here is automation. At 3Pillar we believe strongly in automation and have built strong capabilities in QA Automation and DevOps. Both of these areas allow the teams to move faster, which frees up their time to focus more on quality. With QA automation, every piece of code going into production is tested through automated test scripts, which can be done by engineers themselves and it reduces the time spent back and forth between QA and Engineering, in addition to speeding up the core QA activity itself. Similarly, DevOps allows the teams to confidently move code into production without having to deal with individual issues of the code environment.

These efforts will not eliminate the speed v/s quality trade-off. Instead, these efforts will help your team get stronger at managing it in a manner that adds value to your business and to your teams. So where to get started? For me it starts with the leadership. Have a strong product leadership, make sure they have a clear understanding of the business and access to required information and data. Empower them to make the right decisions for the business and then provide any needed support. A strong leadership will trickle down the right focus and mindset into the broader team.