The Product Is the Variable
Photo by ELEVATE on Pexels.com

The Product Is the Variable

It dawned on me recently that there is a radical transformation in our conversation about digital product development as a result of the (admittedly slow) but inevitable shift towards managing to outcomes. For decades the “fixed” component of our product conversations was the product itself. Sure, we may have shifted on deadlines, scope and or design choices but the question of “will we ship it?” was never in doubt. The product was definitely going to happen.?

Product Deployment Is No Longer Certain

With the shift to continuous deployment, testing and integration systems (aka DevOps) the systems we build have taken on two important new qualities:

  1. They never end?— We work on our products, today, “forever.” There’s no fixed end date for the features we are building. Sound strange? Ask yourself, “When is Netflix done?” Replace “Netflix” with any other modern company and it becomes clear that our products and services live forever. There’s no explicit end date. At some point, we decide they no longer deliver value or the investment necessary to extract more value from them isn’t worth it and we move on to something else. Until that point, we have to maintain and optimize these systems continuously.
  2. They provide a continuous feedback and learning opportunity?— because these systems are always in flight, delivering value (or not), and providing a service to customers, we continuously learn how well they’re performing. We now have an incredible opportunity to determine where to best focus our efforts to continuously improve these systems for our customers.?

These qualities force us to consider a different measure of value than in the past. We no longer need to focus on whether or not we’ve delivered a specific feature. Instead, we focus on what our customers are doing in the system. Are they successful? Are they using it in a way that benefits them? Are they doing what we expected? Something else? Our fixation is no longer on whether or not a specific capability has been deployed but rather, “is the system delivering value?” A determination to “just get features out there” no longer makes sense in this new context.?

The Product Is the Variable

The modern nature of software focuses on deploying the least amount of code that delivers the highest amount of value. Why? Because we have to live with that code forever. Our new measure of success is customer behavior — or outcomes. The behaviors and changes in those behaviors that we want to see in our customers are our new, fixed, measures of success. The way we achieve those behavior changes become the variable. The product is the variable.?

There is an infinite combination of code, copy, design, value proposition and business model that may deliver our desired behavior changes. We mix, match and experiment with various ways to make our offering more valuable to our customers. The goal is fixed as a change in the behavior of our customers. We keep adjusting and (hopefully) improving the product until we reach our desired level of behavior change.?

This Requires a New Mindset to Product Development

Accepting this change to the way we run our teams and organizations is not going to be easy. It’s a significant mindset shift. It’s easy to think of the product as the goal. We can clearly write down what we believe it should do, design it to do that and deploy it. Sadly, this doesn’t guarantee our success. It only guarantees the deployment of code (and subsequent technical debt). Product variability may scare stakeholders. “What are we building?”, they’ll ask. Ultimately we need to change that question to, “How are we trending towards our desired behavior changes?” This will take time but it’s inevitable. Our modern tech stacks demand it.?

Alan Graham

Project Management expert (ex-PMO head), Lean organisation analyst/designer, Lean agile enterprise and team consultant, PMO and PjM coach. My goal is to help your organisation reduce waste and deliver more value.

1 年
回复
Jeremy Bird

UX Design & Research Leader | 23 yrs Design | 15 yrs UX | 8 yrs UX Management

1 年

“…and how we can change their behaviors” is the part of Lean UX that has never sat right with me. The goal shouldn’t be changing users’ behavior. It should be UNDERSTANDING user behavior and then enabling THEIR goals and jobs to be done more effectively. We want to create better outcomes and as a result more successful products not by getting users to change their behavior to what we want them to do, but by enabling them to achieve their goals and desires more effectively and enjoyably with each release. I know Jeff that your focus is on learning and better outcomes, but I think that by focusing on “behavior change” your message can be misinterpreted. I can’t tell you how many companies I’ve seen whose whole focus is to drive behavior change to hit vanity metrics. The problem usually is usually more our understanding of what drives user behavior we see rather than the actual behavior itself.

Patrick Verbruggen

Product Development Excellence for Hightech | Building better systems better and faster | Cyber-Physical | FlashDev?

1 年

It’s all about the #jobstobedone and the underserved desired outcomes. The product or service is ‘hired’ when it serves the job better than others and just as easily ‘fired’ when it doesn’t.

回复
Reg Hawkins

DevSecOps Architect, Agile Coach @ HCLTech | ISTQB, MCPS, SAFe?

1 年

Thanks for posting, thought provoking I like the focus on behaviour change.

回复
Nimish Kasar

Driving Customer Experience through Discovery & Design Management

1 年

Very true!

回复

要查看或添加评论,请登录

Jeff Gothelf的更多文章

社区洞察

其他会员也浏览了