Excerpted from the Authority Magazine interview with Rachel Kline and John Sadler
RK: Based on your experience, what are your “Five Habits That Can Accelerate Product Development Cycles?” If you can, please share a story or an example for each.
1. Customer contact, customer contact, customer contact
Any new product or service is an uncertain undertaking. One of the biggest uncertainties is whether if you build it anyone will buy it, followed closely by what characteristics really matter to customers. Success hinges on learning both as quickly as possible and keeping up with the critical characteristics as the market changes over time. In a recent interview Ford CEO Jim Farley said “we didn’t know that the main reason people are buying the F150 (Lightning) … is because it can power their house for 3 days. We didn’t know that a mobile battery … was going to be that evocative” This feature was an experiment, and it yielded surprising and very valuable knowledge. A team must get out of the building and take a few chances to figure that out.
2 . Quality and Cadence over Scope
This is a mantra for me. Deliberate or not, any product organization arranges these three priorities in some order. When there is no agreement or direction it’s usually Scope, Deadline, Quality, meaning that the marketers dictate requirements and possibly a deadline, finance dictates a budget, and when the developers run out of time, quality goes begging. When teams put scope first, they usually do a poor job of delivering on a repeatable release cycle, and this exacerbates the scope problem because the marketers don’t know when they are going to get another chance to ask for capabilities. Worse, leaking quality issues into the field causes chaos that slows development much more than we imagine. It’s a death spiral.
When leaders put quality first and ask everyone to work on a cadence with scope as the dependent variable, it’s much easier for the team to settle into a rhythm and improve their productivity over time. At Agilent, we more than doubled our same dollar productivity this way over about three years.
When you’re late with a release, all your stakeholders get upset. Slipping a feature to the next release inconveniences a smaller constituency, and if you are good at cadence they know when they will get what they wanted. High quality cadenced releases with variable scope are a win all around but are not intuitively obvious.
3 . Starting integrated and staying integrated
Another big uncertainty that’s especially important with software and hardware/software systems is integration. Traditional product development breaks the product into components or subsystems, develops the subsystems separately, and then integrates and tests them at the end of the development cycle. This leads to disappointment and delay when things don’t integrate because of misunderstandings that happened a long time ago. A better approach that is central to lean / agile development is to start with an integrated system and keep it integrated while growing the capabilities of the integrated system. This speeds development because it moves the integration risk forward in the product cycle to a time when the product is simpler, avoids development of orphan capabilities in one component that the system never uses, and because the integrated system can be demoed to customers so that the team can learn what really matters as they develop. Development is a process of discovery. Staying integrated enables that discovery to proceed on a fine timescale.
4 . Psychological safety and bias for learning
Google’s project Aristotle famously examined the characteristics of high performing teams. They found that the most important characteristic was psychological safety – people’s perception of the consequences of taking an interpersonal risk. When team members are confident that they will not be punished or embarrassed for admitting a mistake, asking a question, or offering a new idea, you have the foundation for a culture that values learning.
We worked hard to grow this mindset at Agilent. It took time and very consistent leadership for people to believe that improvement was valued over perfection and that good ideas could come from anywhere within or outside our organization. But once they did believe it, it was exceptionally powerful at igniting a storm of innovation and excitement to partner with us. One VP made financial sacrifices to fund a team led by our division and collocated with his. That massive show of trust blossomed into a very high performing team. Being willing both to listen to and adopt good ideas from outside our own team built the bridge.
5 . Evidence
Expert opinion is good when you don’t have a better alternative, but everyone has an opinion and it’s hard to arbitrate. Opinions uninformed by fresh evidence tend to lag market moves and miss opportunities to innovate. At Agilent, as the software division in a hardware company, we worked hard to develop evidence sources that my hardware peers took for granted. We were unable to see win/loss data for software sales because leads were tied to hardware in the CRM, so we had to find other ways to measure it. We hired a data scientist to help us develop tools to analyze the rate at which our software attached to hardware sales by region, product type, and other factors. It was a struggle, but we succeeded. This helped us target growth opportunities more effectively. Once we got right with quality and customers started to see that we were delivering on a cadence, we were able to engage with them more directly to talk about the future, which gave us the opportunity to do qualitative analysis as well.
RK: What are some of the common pitfalls that you see product teams fall into when trying to accelerate their development cycles, and how can these be avoided?
Doing the wrong thing faster – setting challenging deadlines without changing the scope > deadline > quality model creates stress and a culture of deception as people desperately race to check off scope and push defects out later in the cycle. To accelerate development cycles, you start by laying a foundation of repeatable cycles, then find the bottlenecks and relieve them.
Neglecting overhead time – there are activities that take the same amount of time no matter how short the cycle, unless you do something about them. One example is your build and test cycle. Unless you measure the time and set goals to drive it down, it will dominate your cycle time and reduce your team’s productivity at shorter cycles. Another example is planning time in scope driven teams. Planning consumes your most experienced people, so it’s a double penalty if you plan work that doesn’t get delivered.
Failing to invest in build and test automation – to build a skyscraper you need scaffolding. The scaffolding for software is automated build, test, and release. If it’s underinvested, then manual work happens instead, and this starts to dominate as cycle times get shorter.
Doing waterfall development with short coding cycles – because the development is discovery, and waterfall assumes that you can know all the requirements in advance and integrate and test at the end. And that’s just not supported by experience.
RK: Can you share an example of a time when you had to make a tough tradeoff between speed and quality during a product development cycle, and what was the outcome of that decision?
That’s a false dichotomy. Quality and speed are natural allies. The real tradeoff in organizations that want to go faster is getting right with quality by deferring new feature development. Sometimes that’s called “go slow to go fast.” I had to do that at Agilent to help the team fix old field defects so that they could move faster later. When your customers, sales, and support teams are all angry at you for poor quality it’s very distracting to the development. Constant firefighting is distracting, and distractions slow development more than the distraction time alone would suggest.
RK: How important is a data-driven approach to product development, and can you share a story where data significantly influenced your decision-making process?
Good evidence – both qualitative and quantitative – is essential to effective product development. At Agilent we developed data that suggested that our biggest market opportunity outside Asia was our own legacy installed base. Qualitative analysis showed that we had left too many adoption barriers in place for the installed base to switch, so we invested in removing those barriers to drive growth in adoption there. It worked.
RK: Can you share an instance where user feedback led to a significant pivot in your product development strategy?
We partnered with an innovative team at a prominent pharmaceutical company who were developing ways to reduce errors in the lab by eliminating unnecessary data entry steps and having the software take more responsibility for goof-proofing lab processes. They were extremely influential, and the alliance shaped our strategy. We had been struggling with a technology-led desire to find some application for big data in the lab, and we realized that a more immediate opportunity was to reduce quality issues through fine-grained workflow automation.