Continuous Product Design: Q&A from the LEAP Dive.

Don Fotsch is the COO and co-founder of GreyscaleAI. He has spent his career building great teams and standout products at companies like Apple, PayPal, John Deere, and Express Scripts.

Michael Spiteri is the Global Head of Insurance Transformation and Innovation, HSBC Life and Partnerships. He specializes in helping organizations implement technology that transforms their business and operating models.

Earlier this month, Don and Michael met with Mario Ciabarra, CEO of Quantum Metric to discuss Continuous Product Design in theory and in practice. The conversation began with a panel at LEAP 2021, Quantum Metric’s annual summit for digital leaders, and continued at LEAP Dive last week.

Here’s a look at their conversations and a continuation of the questions they were unable to answer during the live event.

How do you advise companies to “fail fast” in relation to speed? It seems like moving faster can lead to doing too many things simultaneously. How do you recommend helping organizations move on from tasks that have little benefit to employees or customers so that they can focus on the right tasks with the greatest impact?

• Don: Personally, I think the phrase “failing fast” is uninspiring. Instead, I think of it as “learning fast”, and the f word is simply a necessary step in the learning process. Humans are creatures of habit, and to change a habit we need to replace it with a better one. Start by picking something small (e.g., top one or two support call generators) and listening to the direct Voice of Customer (via Qualtrics for example; see Feedback link at bottom of PayPal footer). After that, you can begin working cross functionally to find and fix the root cause of a problem. And don’t forget to perform a proof of concept (PoC) along the way, since it will help validate the number of customers affected by a specific backlog item, as well as the financial benefit of addressing the issue.
• Michael: Like Don, I would talk about “learning fast.” as it has a different context and connotation and, importantly, conditions us to behave differently. Learning is a growing, maturing experience – failure is not. Brene Brown would rightly talk about vulnerability and how allowing ourselves to show our vulnerability after a ‘failure’ is also incredibly important. Anyway, back to the topic. The key things you must do to avoid disappointment and accelerate learnings in my experience are:
  • Agree what you’ll stop doing while you pursue the alternative innovative or disruptive route. If you can’t decide or agree on what you’ll stop doing, that’s generally a recipe for disaster.
  • Agree what capacity (in terms of dollars, people, and skills) you’ll need to do things faster.
  • If you don’t have the budget or people you need, then make the most of the time that you have freed up in what you can agree to stop.

Can you talk a little bit about what method you use, and your general perspective on balancing speed with quality?

• Don: It’s important to have baseline priorities that are known and executed against every single day. At John Deere, it was: Safety, Quality, Delivery, Cost; in that order. At my current startup, it’s: Safety, Reliability, Delivery, Cost.Here’s the important part: sometimes you have to ship something when it is “Good Enough,” even though you’d like it to be better. But this is simply part of the process. Just remember to plan for and have the discipline to “finish the job” so everyone on the team can be proud of their work.Platforms like Quantum Metric provide great tools that help keep companies honest. If you “cheat” (e.g., not cleaning up after the parade of rushing a “good enough” solution out), the Quantum Metric dashboard and Opportunity Summary will keep the whole team updated on what happened.
• Michael: Speed and Quality – now there’s an interesting mix. Quality is a highly subjective word and is a bit like ‘authenticity’: you know when it’s not there but it’s bloomin’ hard to define in absolute terms. So the best approach for me is to define what the terms ‘speed’ and ‘quality’ mean for the customer experience you are trying to deliver. Your team should agree on a specific goal and say, “We will create a quality experience for our customers that enables a customer to achieve outcome abc in xyz time.” Next, you need to agree on how long you’re prepared to wait (and how long you think the customers will wait) for your definition of quality. Next, compare this measurement to your definition of speed.Watch out for the thinking trap, the idea that quality and speed are in competition with each other. They may not be if you have the right tools, approaches, and resources. Final point: I suspect that being efficient in a DevOps context has a role to play here. I’ve experienced first hand the tension that exists when we need to ship new products and features at an increasing rate to catch up or overtake the competition. If we don’t plan adequately for product maintenance (or product management, to be more precise) then we increase legacy tech debt and eventually we reach a quality-speed crunch point.

How do you balance carving out time from an existing team’s schedule (which feels right) versus pouring additional funding and standing up ‘side resources’ dedicated to quick fixes when a problem arises?

• Don: Accountability is very important. At Apple, Amazon, PayPal, and other top tech companies, you’ll find that there are very few “side resources” for quick fixes. Why? Because great companies encourage employees who create issues to fix them, which is precisely how you build great habits. If you make the mess, you’re held accountable, so you have to fix it, too.So in this regard, one way or another, you always “make time” on the existing team to fix issues created by the team. The one exception would be a “design for cost” iteration of a product, a common practice at Apple. But when you think about it, you’re really not “fixing cost”–you’re performing another design iteration to maintain functionality while taking cost out.
• Michael: I agree with Don–watch out for the ‘quick fix’ thinking trap. This is another example of the tension between the need for an immediate feature and performing a fix “on the side.” It’s the same thing as “scope creep” in waterfall: we agree to do something on the side and as a result we can’t deliver the thing we actually wanted to. It’s better to be the difficult person who says no to the side resource request but delivers a fundamentally great customer experience. This is at the core of Product Management in a modern organisation–and a major discussion point in the field itself.

How would you pitch Continuous Product Design to teams that do not have capacity or the will to engage in CPD. What would you say to people who perceive the practice as high effort?

• Don: I wouldn’t “pitch CPD” per se. Instead I would ask the organization, “What are our metrics of success?” These metrics tend to be some form of customer adoption (such as market share) and financial success. Then I would press further, “How are we going to hit those metrics?” Once I have the team thinking about metrics, I would show them how to use a simple process (CPD) and great tools (Quantum Metric) to improve the team’s effectiveness and efficiency so that they can hit those metrics. Remember, using CPD and Quantum Metric is not about asking what we want to achieve for customers and shareholders. Instead, it’s a question of, “HOW are we most effectively and efficiently going to deliver together for customers and shareholders, and HOW are we going to get better and faster at that every day?”
• Michael: What Don said!

How is CPD implemented in a waterfall/agile hybrid model?

• Don: I would say CPD & the Quantum Metric platform are somewhat agnostic to the software development methodology used by the development team. CPD and Quantum Metric can help teams using any methodology align around the customer and related financial results.That said, I’d expect the customer and financial results to come much, much faster when CPD and Quantum Metric are integrated with agile methodology. Agile left something important behind–the customer! Together, CPD and Quantum Metric address that shortfall head on. This is sorely needed at many organizations, and especially those that view a financial budget as a “plan.” A budget is a budget. A plan, which focuses on metrics such as new and retained customers, is a set of accomplishments that, when realized, produce the desired financial results.
• Michael: Regardless of delivery methodology, we need to know what customer outcomes and business impact each delivery activity will have, right? In the waterfall model, this would be conducted in a business/customer requirements context. You would create a scope before driving a set of technical requirements (something like the V model below).

(Source: javatpoint.com)

So, in a waterfall context, CPD is so critical, since the methodology helps us to understand what our customers want or need BEFORE we build it.

In an agile context, CPD is a fundamental component of the Discover, Define, Develop, Deliver continuum. And without it you still have business people or engineers guessing what they think a customer needs. And guess what? When you’ve committed time, resources, money and perhaps even your reputation without truly understanding where the biggest customer impact is, you really don’t want to listen to customer feedback–you just want them to love what you’ve built. I’ve experienced this as a customer myself: Product owners have sat over my shoulder to tell me that I was using a product incorrectly, when really it was designed poorly. CPD disrupts this thinking and encourages you to discover needs directly from the customers themselves.

Don is right though it’s largely agnostic. I used to describe the waterfall/agile hybrid model as Fragile delivery (with tongue in cheek, of course). But you should be clear about why you’re choosing a hybrid delivery model.

These are the first half of the questions we received. Stay tuned for the rest in Part II of the post!