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.

Post to Twitter Post to Facebook

This article was published on Wednesday, November 12th, 2008 at 9:24 pm and is filed under Agile, Product Management, Requirements, Software development.
You can leave a comment on this post

11 Comments

  1. I love these articles! They are spot on!

    When is good enough? Good enough is when the pain is not mitigated by the provided value, and the company has established themselves as an upright place of not only good intentions, but good continual results to continue to grow on that product foundation as well as community support (customers, third party developers, partners, etc).

    This takes time to evolve – but this foundation, like in any relationship, equates to one solidly backed by trust I believe. Customers trust that you are there for them, to solve their problems, to deliver, in short term and long term, and vendors’ desire to continue giving back, gaining and building that loyal customer following.

    With these “true blue” product intentions, iterative development is possible.

    If thought in this light, building SW is not much different than building human relationships.

    With open and telling media outlets (blogs), this is a beautiful silver-lining of social media. Integrity is being brought back into he product schema – and PMs can ack that and work it to their advantage if they know how – with both a short and long term strategy.

  2. Ellen, thanks very much and welcome to Tyner Blain!

    I love how you’ve approached this as relationship development, where it happens to evolve from the creation of software. It becomes collaboration, where one of the mechanisms is delivering software.

    It also helps to remember that we “value communication over…” and that we do work for the business because the value the business places on what we create exceeds the cost of creation. Keeping those in mind, and building on a relationship of trust – just good thinking.

    Thanks!

  3. Scott, this makes me feel better about the never-ending list of cases I have yet to close (and keep adding to). You really only can do one thing at a time, and there’s some comfort in that, because you don’t have to be perfect. You just have to stay disciplined and focused on the next most important one thing the project needs.

  4. Hey Mike, thanks for the comment and welcome to Tyner Blain!

    The funny thing is, in old waterfall projects, that same never-ending list continues to grow, it just either isn’t acknowledged, or isn’t shared, for risk of derailing the project.

    I always visualize a kid sticking his fingers in his ears and shouting “blah blah blah, I can’t hear you! I’m not listening!” As if by ignoring new information about your market, it somehow doesn’t exist.

  5. This is a great post – love it. The most successful teams that I have been part of had a real understanding of “enough” vs. “perfect” and were flexible enough to move from one to the other as was needed.
    April

  6. Unless the requirements are static (it is possible, say in projects of a scientific nature) for the lifetime of the product development, the product development team that “satisfices” could have time on their side. They would receive feedback from the real users of their product in this time. They could use this real-world feedback to push their product closer to “perfection”.

  7. Thanks Inder, and welcome to Tyner Blain!

    I haven’t worked on any projects where the requirements are truly static. Even something in the scientific domain, where isolating variables and controlling (repeatable) procedures may result in “static” operational requirements can still be dynamic. Consider the potential value of finding novel ways to slice and dice the resulting data. When I was still doing engineering work, many times when running experiments, my goal was find insights into behavior and trends, and reviewing the data would often lead me to want to review the data in unanticipated ways.

    Your point about real-world feedback is spot on!

  8. Great post and certainly speaks to a common problem in product development organizations. This belief that a perfect solution must be developed before anything can be provided to customers often results in the release of a “full featured” product that completely misses the mark. I love the satisfice term, had not heard that before, and will use it in my discussions. It also speaks to the concept of focusing on minimal market features, release quickly, provide value, and begin to generate revenue.

  9. Hello,
    Can u explain more on minimal market features.
    Thanks in advance.

    • Hey Monika, welcome to Tyner Blain and thanks for your question!

      “Minimal market features” is short-hand for describing the product that is just barely good enough to go to market.

      Depending on your strategy, “good enough” may mean “technically capable of solving the problem” or may mean “a joy to use, when solving the problem.” Also – depending on your strategy, you may need to solve one or more problems; and you may need to solve them for one or more personas or market segments.

      The idea is that you don’t delay the release of your product until you have built something that solves every problem for every customer in every market segment. Figure out something that someone will buy, and get that into the market as soon as possible, then do incremental updates to make the product better.

      Does that help?

2 Trackbacks

  1. By Scott Sehlhorst on April 1, 2010 at 3:46 pm

    R @barbaragnelson thanks for the RT on minimal market acceptance – for deeper dive on #agile sprint level see http://bit.ly/9H7VHO

  2. By Gregory Yankelovich on December 20, 2011 at 10:48 pm

    RT @sehlhorst: Satisficing Sprints http://t.co/L4UjCyIE #prodmgmt

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>