Jonathan Steiman
  • Blog
  • Resources
  • Photos
  • My Dad's Photos
  • About Me
  • Contact

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

6/7/2012

2 Comments

 
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.
2 Comments
    Picture
    JONATHAN STEIMAN
    Follow @jonsteiman
    I'm the Founder and CEO of Peak Support. This blog is my take on early-stage companies and innovation. Every so often, there may be a post about culture, networking, family -- you name it. After all, what is a blog if it isn't a tad bit unstructured.

    Enter your email address:

    Delivered by FeedBurner

    Archives

    December 2016
    August 2016
    December 2015
    August 2015
    May 2015
    September 2014
    July 2014
    April 2014
    March 2014
    December 2013
    August 2013
    June 2013
    May 2013
    April 2013
    March 2013
    October 2012
    September 2012
    August 2012
    July 2012
    June 2012
    May 2012
    April 2012
    March 2012
    February 2012
    January 2012
    December 2011
    November 2011
    October 2011
    September 2011
    August 2011
    July 2011
    June 2011
    May 2011
    April 2011
    March 2011
    February 2011

    Categories

    All
    2011
    Accredited Investors
    Airbnb
    App
    Apple
    Bankrupt
    Bankruptcy
    Benjamin Graham
    Best New Business Blog
    Beta
    Blog
    Bob Dylan
    Capital Asset Pricing Model
    Capital Requirements
    Capm
    Coaching
    Codecademy
    Codelesson
    Competitive Strategy
    Continuous Improvement
    Convertible Preferred
    Creative Destruction
    Crowd Sourcing
    Crowd-sourcing
    Customer Insights
    Database
    Data Repository
    Dcf
    Debt
    Design
    Development
    Discounted Cash Flow
    Disruptive Technology
    Ed Tech
    Education
    Education Technology
    Elizabeth Warren
    Entrepreneur
    Entrepreneurship
    Ephemeral Era
    Equity
    Facebook
    Facebook Marketing
    Facebook Mobile Advertising
    Finance
    Finance-ability
    Fortunate
    Function
    Functionality
    Fusion Tables
    Google
    Google Chrome
    Google Docs
    Google Fusion Tables
    Google Spreadsheet
    Google Table
    Hiking
    Innovation
    Instagram
    Institutions
    Intensity Map
    Internet Access
    Internet Platforms
    John Rawls
    Joseph Schumpeter
    Leadership
    Location
    Location-based Data
    Management
    Marketing
    Mba
    Microsoft
    Microsoft Access
    Mobile
    Model
    Nda
    Networking
    Novartis
    Operations
    Participating Preferred
    Pay-off Diagram
    Performance
    Personal Improvement
    Peter Drucker
    Polaroid
    Portfolio Management
    Postagram
    Private Equity
    Product Development
    Risk Free Rate
    Risk Management
    Scale
    Schedule
    Sec Regulations
    Sincerely
    Social Media
    Standards
    Start Up
    Start-up
    Steve Blank
    Table
    Talkto
    Taxation
    Ted Fortsmann
    Treehouse
    Twitter
    User Interface
    Valuation
    Value Chain
    Venture Capital
    Venture Finance
    Warren Buffett
    Water Safety
    Web 3.0
    Working Capital
    Y Combinator

  • Blog
  • Resources
  • Photos
  • My Dad's Photos
  • About Me
  • Contact