Satisficing Sprints

Satisficing probably makes more sense than perfecting your product.

Can? Open.

Worms? Everywhere.

Are we really saying “don’t make it perfect?” Yup.

Product Perfection

A perfect product will be successfull. It will solve the right problems, generate as much value as possible, and be so intuitive to use that you don’t even realize you’re using it.

Perfection is a bit of a catch-22, however. When I was still working as a mechanical engineer, I joined a team who introduced me to my new role with the following statement about the product I was going to replace: “the design engineers are really good, they designed a great <product> – the only problem is that we can’t build it.”

My first thought – “you’re not using the same definition of great that I use.” The same holds true for the perfect product. Perfect at what cost? If you spend too much making the product otherwise perfect, you won’t make enough money selling them, or your customers won’t benefit enough from using them, so you won’t sell as many, so your profits will be lower, so …, so …, and so on.

You can aim towards perfection, and still probably be ok, because you’ll never get there. Your ideal product is a moving target, because your market is moving. Since you’re prioritizing the most important capabilities to build at any given point in time, you’ll never reach the end state of having done “everything.”

There was a math problem that made my head hurt when I was in college. It went something like this: If you were 100 feet from your house, and every hour cut the distance by half (after one hour, you were 50 feet away, after another hour – 25 feet, etc), and it was going to start raining in 10 hours, would you be inside before it started?

What if it wasn’t going to rain for 10 days? Or 10 years?

That may be why I became an engineer, and not a mathematician. To me, at some point, you would simply take one reasonably sized step, and be in the house. An engineer would be inside the house before it started raining – and he’d probably be fixing (or breaking) something. A mathematician would never make it into the house. I could never appreciate that kind of math. But I like fixing things.

Every capability you add, or every problem you solve, gets you closer to perfection. The problem is, it doesn’t get you “10 feet closer”, it is more like “30% closer.” And like the mathematician, you’ll never get there.

Even the engineers won’t get there, however. Every solution you deliver to your customers changes the definition of perfection. Each solution enables new opportunities, and exposes new challenges. Perfection becomes a moving target.

Product Paralysis

People talk about analysis paralysis fairly often. Product paralysis comes when you spend so many cycles agonizing over the perfect thing to do, or the perfect thing to do next, that you don’t do anything. Its the product management version.

I was on a call today, introducing some users to a product we’re developing. We just stood up a website release – the first sprint that has enough content to be independently consumable by non-software folks. One of the folks on the call, when trying to explain how agile works, and how user acceptance testing would work, made a statement that I thought failed to capture the essence of what we were doing (in a language that the audience could appreciate). Paraphrased, the statement was – “in an agile project, there is no ‘release date’, the website will be done when it is done.”

I interrupted to share how I think about this project, and agile in general – “In this project, we’re building a release for you every two weeks. Every two weeks, you get to decide if it is ‘enough’ to share with customers, or share with more customers.” [Note: In that statement, “customers” are people who use the website to purchase products from our client, who is also our customer.] This project involves replacing a legacy system, as quickly as makes sense. The new solution introduces new capabilities (and value) relative to the existing solution. Today, it also lacks many capabilities (and value) provided by the current solution.

The question we are working with the business to answer is “when do we switch from the old system to the new one?” There are at least some people who insist that we cannot switch over until all of the current capabilities are live in the new solution. If we use that metric (and we may – that has not been decided yet), there will be a period of time where the new solution is more valuable than the current one, but that value will go unrealized. I think that is another form of product paralysis. We won’t have perfect data, so it will be a qualitative decision. Right now, we’re trying to establish an alternate view of “enough”, and then predicting how long that will take, to manage expectations with stakeholders. Fun stuff.

Sprint Satisficing

Ivan Chalif just published a review of the book, Don’t Make Me Think, by Steve Krug. In his review, Ivan points out one of the themes in Krug’s book – doing “enough.”

Many choices that a Product Manager has to make are based on having to balance between the optimal solution and what can be done in a given time frame with the available resources. We bet that if we satisfice, it will be enough to address the short-term requirement or at least buy some time to refine the feature in a later release.

That made me remember another book, The Paradox of Choice, by Barry Schwartz. Another good book, where a central theme is that when given an arbitrarily large set of choices, people don’t choose optimally – they focus on eliminating choices, then choosing the best from a select few options. If I remember correctly, Schwartz argues that people don’t optimize when faced with too many choices, they satisfice.

When it comes to determining what to include in a particular sprint, we’re faced with an arbitrarily large set of choices, so we prune. And then we satisfice.

In another conversation today, one of the developers asked an insightful question about one of the stories that was committed for the sprint. As part of answering that question, we realized that the “perfect” answer was to change the design approach for that story, resulting in extra work that would push the team beyond capacity for the sprint. We have a theme for the sprint, and this story is a key element in that theme. If we have to push something to a later sprint, we want to push something else.

The story was written for three classes of users – logged in users with existing accounts, people who just created their accounts, and people who didn’t have (or want) accounts. The project involves integrating COTS (customized, off-the-shelf) software with legacy systems. We discovered that the design changes would only be needed for people who did not have accounts. The theme of this sprint is to enable an end-to-end path through the site (essentially, completing an epic). We decided that we would be satisfied by completing the epic for the logged-in users in this sprint, and add the other users in the next sprint. That met our tactical goals for completing the epic. Our alternative would have been to delay another story (or two) to a later sprint, just to be “perfect” with our epic. This is the better solution, in this case.

What made this possible was that we remembered that each sprint asks the question about the solution – “is it good enough?” And by implication, each sprint asks the question about each story – “is this approach good enough?”

We decided that today landed in the “a good day” column on the ledger.