Cutting Corners

On Monday morning, Jimmy pulls up in front of Starbucks at 8:16 am on his way to work. He decides to forgo paying for parking. It only costs $0.25 / 15 minutes but the hassle of navigating the parking app on his phone isn’t worth it.  "I'll only be a few minutes," he reassures himself. After ordering his favorite drink and paying $6.38, Jimmy patiently waits for his name to be called. “A venti caramel latte for Timmy,” someone yells. Eight minutes later, he heads back to his car and drives off. The following days, Jimmy repeats this routine. However, on Thursday, as he leaves the store, his heart sinks when he notices an orange envelope placed on his windshield—a $60 parking violation ticket.

It’s not uncommon for companies that build new products to cut corners in areas where they should aim to raise the bar. Instead, they put their energies into building more feature rich products, a strategy that increases execution risks, and hurts the company’s short and long term chances of success.

I would like to argue that there are three reasons why.

1. Leadership may lack experience in building products in a lean, and agile way. Building a strong culture is an absolutely essential ingredient but it may not be enough. It is considerably more complex to build a team that can establish really strong engineering, operational, and data-driven strategic disciplines that are designed for scale. It requires leaders with enthusiasm and ability to articulate their vision, but also equipped with the hard skills to be able to steer the technical strategy towards the right direction.
2. The product in question is just not mission critical for the company, both in potential value as well as investment risk. If the product fails to deliver, it doesn’t mean the company fails. The company knows what it needs to do to maximize the chance of success but it intentionally chooses to divert its investments into its top priorities, making a calculated bet.
3. While (1) or (2) represent a small number of orgs, a mix of (1) and (2) (lack of experience combined with prioritization challenges) describes a 2-D plane where most companies that build products are fighting their daily battles. In this place, it isn’t always quite clear if one decision is better than another and progress can be difficult. Companies are also constantly moving up/down and left/right on this plane as they battle competition, an ever-changing workforce, and a fast evolving tech ecosystem.

There are ways to steer the ship more towards a successful destination by first recognizing and understanding that some easy-looking strategies are not always the most successful ones. Examples:

• Funding a team to "go away somewhere" and come back with a product ready for launch in 10 months is rarely the right strategy for building many products. Instead, a team should be tasked with bringing a much smaller version of that  product to a limited number of customers much sooner so their feedback can help inform/adjust the strategy. This is just the Agile philosophy at work.
• Deprioritizing necessary infrastructure and processes such as having proper end to end deployment automation and rollback, collaborative tooling, automated security, increases daily toil, dampens collaboration, and kills innovation. These things may be not very exciting to build but they are critical in maintaing velocity as the product scales and the team grows.
• Not setting a high enogh bar for the quality of the system design, the written code, the testing tools and release processes, not establishing the means for tracking key success/failure metrics – these directly impact the product quality and set an upper ceiling for hiring and retaing the tech talent that becomes very difficult to raise later without a significant shift in strategy and investment.
• Underinvesting in the customer support experience by not creating an operationally mature, cross-functional culture where everyone in the company feels responsible for the customer outcomes, a culture where everyone understands the importance of reacting to customer issues swiftly, thoughtfully, and proactively working to improve them.
• Underinvesting in building data “eyes” into an active product from the very beginning and as part of the implementation strategy. Leading a product that lacks data analytics, operational and technical metrics is a lot like flying an airplane through clouds with navigational instruments turned off.
• Not consistenly reviewing and updating the execution strategy on a regular basis so it can be frequently course-corrected for what is being learned through each iteration and customer feedback.