Innovation and Feasibility

When our internal Innovation Team gave me demo of a prototype that could make stock trades using Alexa, I was VERY impressed. A true innovation, trading by voice would delight customers and put us ahead of the competition. There was one problem though, the prototype wasn’t compatible with the company’s legacy trading platform. After that demo, many meetings ensued between the Innovation Team and the teams responsible for the trading platform. There were also meetings with Amazon’s Alexa team. Finally, the legacy platform team insisted it was too much work to make Alexa security compatible with internal systems, so trading via Alexa gutted. In the end the only Alexa functionality was providing ticker prices. This was not impressive, and customers never got the chance to be delighted by voice-activated trades. What happened?

According to research, 95% of innovations fail. We often assume these failures “don’t solve a real problem for customers and users.” This is a bad assumption. Innovations often fail because they aren’t compatible with existing systems, there is little understanding of what it will take to scale for production, or the relationships to overcome obstacles don’t exist. In short, Innovations fail on FEASIBLITY. In the case of trading via Alexa, the Innovation Team had no incentive to build relationships or test legacy system limitations until it was too late for discovery, and too late gain buy-in to solve for security issues.

Outsourcing (and insourcing) innovation is popular. Whether by creating a special team inside the company itself, or by using an “innovation provider,” this approach can remove organizational, systemic, and cultural constraints to allow for experimentation, failure, pivots, and rapid prototypes. However, if your goal is to commercialize, any innovation must be tested early for feasibility and overall organizational impact - this is where using an outsider team fails.

The incentive to build relationships, understand technology challenges, and assure feasibility for scale simply doesn’t exist in most outsourced/insourced models. The alternative? Understand Value, Usability, Viability, and Feasibility all to be tested in the innovations cycle and leverage internal networks. More on internal networks in this 2017 article from MIT Sloan Management Review.

In short, when it comes to Innovation, solving for feasibility is just as important as whether you are solving a real problem for customers and users.

We’ve built too much

Remember when we thought software was “free”?

We know better now. So many highly talented engineers are working on “KTLO” projects or migrations projects that take months (or years) to complete. Many are under pressure, wrangling poorly implemented legacy code, to implement new features that may or may not be used. Often in an attempt to create incremental value for a mature product.

The data has been around a while now - More than 60% of code in production is rarely or never used. Agile’s promise of “maximizing the work not done” to avoid this scenarios has failed. "Build the Right Thing" had always been an equal partner of the Agile approach, but this message got lost. Currently, in most mid to large sized organizations, engineering is funded like an outsourced service and Scrum or Scaled Agile practices that focus on output have now been adopted. Is this output going to create success, or torture future efforts to "Build the Thing Right?"

It’s time to re-focus and bring Build the Right Thing back. Relying on a backlog that is ranked by a magical “priority” by some mythical ”Product Owner” has led to backlogs filled with technical tasks. We don't know if what we implement will be used and form engineering teams that are wholly disconnected from strategic or product goals. We push code, and push more code. When we finally integrate and release, we quickly move on. This is not sustainable.

The drive to hire more engineers, increase velocity, and implement more Project Management will only make the drive to output more severe and that in turn will ruin our customer experiences and employees satisfaction.. We don’t need more unused code to maintain ….we need to enable Product Thinking and gain confidence that we are Building the Right Thing in the first place.

The industry has undervalued Experimentation, Discovery, and Design Thinking a decade now- but there is a growing realization that building more is not the answer. Let’s start Product Thinking before weight of unused code crushes us. Every risk is an opportunity. Your biggest opportunity is #productthinking #engineering #discovery #designthinking #agile

What do Product Managers do?

Whenever I’m coaching Product Managers about Product Thinking, on thing becomes clear - Product Managers are expected to do too much. They are accountable for the success of their product. They are told they are the CEO of their product, and must know to know what customers and users need. They must assure that the product is viable, feasible, valuable, and usable. Then they get treated like Project Managers.

Product Managers are commonly driven to deliver multiple projects and are not incented, empowered, or trained to measure product success. Too often, they are not granted the time or access to leverage data to make product decisions, but are asked for meaningless status reports. Many Product Managers don’t understand how to work with technology and are left wondering why projects are late. Product Managers need help.

They need training and coaching, and they need to be adept at communicating how digital products are tied into the overall product and organizational strategy. The most important thing they need is a funding model that supports Product Thinking. Product funding helps Product Managers measure outcomes and creates incentives to deliver to OKRs, monitor KPIs, and measure product performance instead of driving teams to complete projects. Product funding simplifies the world of Product Management and allows them to pivot to true product success. You can read more about why Product funding is so important in this article by @martycagan https://www.svpg.com/project-based-funding/

Product Thinking - Are we losing the narrative?

I thought we were just getting started with Product Thinking, but maybe we are already seeing the beginning of the end of it. From what I can tell,  Product Managers are expected to do too much with no support and little if any experience working with technical teams.  Business Analysts, if they still exist, are now busy doing non-analysis work (like Scrum Mastering).   There is now more pressure to increase output through the predominant Agile frameworks, and marked decrease in collaboration and planning to measure delivery of outcomes, impacts, OKRs, etc..  Anyone else seeing this?  Are you doing something about it in your organization?