Spottah’s Streak Ends: 3 Rules To Avoid Future Thrashes

Over the past six months, Spottah managed to quiet the "Lizard Brain." It was an amazing streak that would make Seth Godin proud. We delivered a minimal viable product, a beta and two Apple App store releases without thrashing. But like all great streaks, ours came to an end. Between Sunday night and Wednesday morning, we violently thrashed. Think boated Great White.

Without getting into great detail, we planned to push an App Store update on Sunday night.  Since releasing our first version in mid-May, we identified a few bugs and “stumble points.” My favorite: Facebook Connect in Norwegian dialect. So we drafted a 20-item requirements list in Pivotal Tracker. One-by-one Spottah’s amazing development team delivered. On Saturday night we received a TestFlight. Every requirement worked. One final call on Sunday to “push the button together.”

Sunday. 4PM.  The team assembled. We agreed: the new build is tight. We thanked the development team. They, like always, said don’t worry about it.

Then it happened. Our partner in charge of the front-end threw out a final request. Our back-end developer said it shouldn’t be too hard, and that he’ll look into it. “Great,” I said. “Look into it. If it isn’t too difficult, go for it.”

And so began the thrash. One fix caused four problems. And in the end, the request had the opposite effect: it slowed Spottah down.

How did this happen? Why am I so upset that we thrashed? And most importantly, how will the team ensure that this does not happen again?

How did this happen?
Over-confidence and a lack of discipline caused Spottah’s thrash.  During the six months the team has been together, there has not been a single programming challenge that our developers could not solve – quickly.  With each precise and timely delivery, confidence grew. Discipline, in turn, waned. After all, why be disciplined in your decision-making when every task is doable?

So on Sunday, when the extraneous request was proposed, I had no doubt that the team could deliver. Instead of being a disciplined project manager and asking a line of questions (Do customers want/need this? How will implementing this one item affect other parts of the application?), I resorted to the worst logic in product development: If doable, than do it.

Why I’m so upset?
I’m upset because thrashing strains the team.

The development team bears the brunt of the strain. Developing a beautiful application that is easy-to-use and reliable is difficult, to say the least. Thrashing makes the process more difficult and lowers morale. Who likes investing hours into building something, only to find out after a few seconds of usage that it makes the product worse? And it doesn’t end there. Additional hours are required to undo the now-useless requirement. It’s like building a house, realizing you don’t want to live on that particular street, and then dismantling the house.

The business side is strained, too. Since the Apple update process requires deliberate action by the consumer, you don’t want to push the product too hard knowing that an update is in the not-too-distant-future. It makes little sense onboarding people on Tuesday only to ask them on Wednesday to update. Since the business-side is measured by active users (at Spottah, at least) it is stressful to delay marketing efforts.

Overall, thrashing harms the team dynamic. While one side of the team burns the mid-night oil, the other is left sitting on their hands.

Steps for avoiding future thrashes
1.    Invest the time up-front to develop a sensible requirement list….and stick to it! Spottah did the first step. We had a requirement list that addressed bugs, UX improvements and performance. We nailed all 20 items on the list. The one item not on our list led to a thrash.

2.    Exceptions to Step 1 can be made but be doubly – no triply – sure you need it. It is naïve to say that you shouldn’t adjust a plan made three weeks earlier. Things change. You could have completely missed something in your customer research. Or, a technology in the stack can change, thus forcing your hand. But before rushing to add an additional requirement:

i. ensure that it is absolutely necessary; and
ii. understand how it will affect the feel and performance of the product as a whole.

3. Don’t get lazy. We were tired and distracted that fateful Sunday.  We had been pushing hard while balancing life; for example, I took the call between my sister’s graduation party and a trip to the movies with my nieces. Under such circumstances, it’s easier to say “Go for it” than it is to ask the hard questions. But in reality, it is easier to be disciplined up-front than it is to unwind a mess caused by small-thinking.

DiMaggio’s streak ended in th 57th game. The Patriot’s Perfect Season slipped away in the Super Bowl. And Spottah’s thrash ended a solid run of ships. But we’re a young team and the new season starts today.