How to Drive Operational Excellence

Problem

Some of the biggest challenges faced by product technology leadership today are:

• Balancing velocity and quality;
• Balancing product features and tune-ups (refractory);
• Balancing staffing investment in product teams and platform teams;
• Determining principles to drive prioritization & decision making for all of the above.
  

There are various factors that should be considered in determining how to address these — e.g. size of the company, phase of the company (growth phase or trying to find product-market fit, etc.), the maturity of the technology team and tooling. There is no right or wrong answer, but ultimately, the largest determinant of success is the ”speed of innovation.”

Actions taken

If we would simplify the world, there are two categories of items in the roadmap:

• Innovation (product features);
• Tune-Up Items driving the speed of innovation.
  

Tune-Up items make up the backbone that enables innovation in the first place. This consists of automating mundane, time-consuming, manual workflows carried out by internal staff (developers, customer support, etc.). Some of the examples could include releasing fast with quality, fast incident detection, and response, building common reusable components, or continuously refactoring to ensure components are secure, scalable, and available, with low latency and continuous delivery.

This amounts to a flywheel, which feeds into itself. Investing in Tune-Up (speed of innovation) items leads to higher development velocity, which then leads to improved product innovation, which further leads to scaling the team, and which then finally, leads to more investment into the speed of innovation.

Product innovation

The prioritization for this category consists of evaluating the impact by answering these questions:

• What is the customer impact?
• What is the business impact?
• What is the operational efficiency of the business impact?
  

Once that has been decided, you need to move on to the How while keeping the essence of “done is better than perfect.” The key here is speed to market and validating the hypothesis using data from customers quickly. Here are some steps:

• Step 1: Early ways to get your hypotheses validated using sketches or prototypes (test builds) sent to only a select few users (beta).
• Step 2: If that pans out, moving to the next step of doing minimal MVP and A/B testing.
• Step 3: Once there is heat on the feature, and it’s decided to ship broadly, taking the time to put the right operational and quality gates to scale the feature to a large audience.
  

The key is follow-through and not run after the next shiny object. Once the team has fine-tuned and adopted enhancements based on data and customer learnings, only then does the feature drive optimal outcomes for the customer. Give teams space and time to complete this last mile of optimizations.

Speed of innovation (Tune-Ups)

Just like product innovation evaluation, we need to evaluate these “run the business” items with a similar lens, e.g., asking questions like:

• What is the customer impact? (e.g., bugs, latency, lengthy turnarounds, lengthy time to value);
• What is the business impact? (e.g., brand trust, revenue impact due to downtimes);
• What is the impact on the operational efficiency of the business? (e.g., the productivity of developers and internal staff).
  

There is no one-size-fits-all approach. The investment that a company makes depends on the product/tech maturity, tech team size, and a number of different business/product lines. For example, a young startup needs to create products and POCs instead of investing heavily in the speed of innovation. On the other hand, a startup that is focusing on growth needs to invest more. Alignment and prioritization with the Product and Engineering teams during company strategy planning is crucial. This should be part of the product and tech DNA of the company and not an afterthought. Alignment is critical in making sure everyone is rowing in the same direction.

Next comes the metric/measurement to inform data-driven decision making. This is achieved by capturing metrics around the product development phase, overhead on production incidents, and defining KPIs to measure the success against.

As feature (application) teams increase or expand to different business/product lines, staffing horizontal teams become critical to laying the technology foundation, driving reusability and consistency. Two areas of horizontal teams are:

• Platform teams: they layout common building blocks that application teams build on or reuse;
• Framework/ infrastructure teams: they layout the tooling and infrastructure framework that applications teams integrate with to drive continuous release with quality gates and to be able to drive fast detection and response with technology.
  

Lastly, we are never done. We need to repeat the process of Align -> Prioritize -> Measure. There will be times when teams might be focusing more on product innovation. Sometimes that might have to swing into focusing on refactoring to meet the speed, scale, and operational excellence. Refactoring is like your car needing servicing; some are lightweight like oil changes OR some are more invasive tuneups.

Lessons learned

• Have transparency and clear communication on decisions and tradeoffs while having the flexibility to align with business priorities and meet hard deadlines, if needed.
• Follow through on execution and delivery of these and measuring the impact.