BONUS: Jeff Gothelf on how to redefine the measure of success for software development

When Agile broken into the scene, it was mostly about the techniques to develop releases of the product quickly. However, that was a time when products were released only a few times a year at best. Today products evolve continuously and that changes how product Owners and Product Managers need to interact with the teams. In this episode, we explore some of the key lessons Jeff has learned working with product organizations all over the world. In short: Product Managers also need to adapt to Agile, it’s not just the teams!

Continuous product development is different from what we used to know as product development

Read on for the detailed show notes and all the links.

In the past, software products used to come in boxes. I remember working with a colleague to optimize our print-to-order process so that we could bring some agility to our CD production process. These processes led the software teams to get “everything” in, which led to a lot of up-front planning and a very waterfall process.

Agile, when it came up in the early 2000’s, it promised a different approach. The iterative and incremental approach brought about by the Agile transformation allowed us to develop approaches that were right for another type of software development: continuous software product development. This, in turn, changes the role of the Product Owner / Product Manager.

This continuous development approach (see Continuous Digital book by Allan Kelly) is our next challenge. Many organizations are not yet ready for this shift.

Creating an Agile culture of continuous improvement

As the focus on continuous development brings about changes, we must also re-think what product development success is in this new context.

It is no longer delivering “everything” on time and on budget (the old project measures).

From a product management / Product Owner perspective, the new success measure is “did we get the change in customer behavior” we expected? For that we must build teams that are able to think about the technology, the customer and the design that will enable that change in customer behavior that we need for the product to be successful.

Books like Barry O’Reilly’s Unlearn helps us define, and act on a the definition of success that is based on “how much can we learn by releasing or testing a new version of the product”.

Jeff also shares a very handy tip to help us change the mindset in our organization: just change the name of the teams. For example, don’t have a “mobile app team”, change their name to “mobile buying experience team”. That will clearly communicate to everyone that the team is responsible for the end-to-end experience for the customers who interact with our company via a mobile device, instead of just working on mobile applications.

This new definition of success also pushes us to think about the outcomes our teams should be focusing on. Leaving the detailed tasks to be defined as the team progresses, and learns.

Are your Product Owners managing their teams for outcomes, instead of tasks?

Helping Product Owners

How do we help our Product Owners to focus on outcomes? Jeff suggests a few techniques, starting with defining a clear mission for the team, and the product we work on. Jeff suggests a technique we can use to help Product Owners define a clear mission, outcome-focused, that will drive the team to think about impact.

As with all changes, we need a way to assess if we are progressing. Jeff shares with us how to measure that change. Product Owners need to work on customer-focused metrics, specifically customer behavior change metrics.

Helping Product Owners and teams develop their Customer focus

As we focus more on the customer, we need a set of rules that help us keep that customer front and center in our approach to work. Jeff suggests:

  1. Have user advocates on the team
  2. Define, and communicate the reasons for working on something (the “why”)
  3. Seek out and connect and establish regular conversations with customers and users

Re-defining the MVP, Minimum Viable Product

When it comes to learning what works, the MVP is the standard and most popular approach. But, unfortunately, some organizations still think that MVP is just about “delivering a poor version of the final product”. That’s not what MVP is about. Jeff refers to the Lean Analytics book definition: MVP is a process, not a “thing” we release and end up calling a product.

The process is simple, but requires a lot of work to get right, and it starts with the following questions:

  1. What’s the most important thing we need to learn next?
  2. What’s the least amount of work we can do to learn that?

In Lean UX, Jeff Gothelf defines his own approach to effective experimentation in the product development process.

Launching many, many more authors to help you improve

Over the last few years, Jeff has helped launch other authors via the Sense and Respond Press, a publisher for the busy executives who need to digest critical topics in short reads prepared for people who need to act on it immediately. A recommended book for Scrum Masters is Lateral Leadership: how to lead without authority.

About Jeff Gothelf

Jeff is a Product person. He believes too much time and money is wasted on ideas that don’t work. The world, driven by technology, is changing too fast for us to reliably predict what will work. Today’s leaders must inspire and collaborate, not micromanage, to drive agility and innovation in their organizations.
Jeff teaches executives and teams to focus on their customers, learn from mistakes and create an agile culture that continuously improves their products and services and the way they work.
He’s also the co-author of several books on the topics related to Agile Product Development.

You can link with Jeff Gothelf on LinkedIn and connect with Jeff Gothelf on Twitter. And for more, visit Jeff Gothelf’s website where he has regular blog posts and the sign-up form for his newsletter.

Leave a Reply

Your email address will not be published. Required fields are marked *