The post-mortem: how small businesses and startups can learn from their mistakes Mike | January 18th, 2010

As you may be aware, last month we launched our fully re-factored site after many months of effort on the part of the team. Not only did this re-launch mean a 100% new code-base, it also meant 100% new hardware at our hosting provider. Our goal was a faster, more stable site, and a code base that allows us to add new features and enhance existing ones quickly and easily. Our community is already benefiting from this: along with the improvements introduced last month, the site’s performance and site stability are greatly improved; in the 30 days since launch our site uptime has been 99.9%!

As good as it felt to launch, the process was not without pain. Wait a sec – what am I saying? What I meant was, as good as it felt to launch the process was intensely painful for the entire team. Many long days, some heated disagreements, more than a few all-nighters, way too many bugs at launch, many customers impacted (and frustrated), and a huge spike in customer service requests served to drain the team, reduce our capacity, and destroy our productivity for weeks. We have emerged from this process older, wiser, more tired than ever, but having learned some truly valuable lessons.

We took some time last week to meet as a team and spent the better part of a day doing our own “post-mortem” on the process. Our goal was to come away with some lessons learned and to use these to inform our internal process and to improve our performance going forward. In 2010 we will be introducing some major new features and we hope to better execute these “mini-launches” and lessen their impact on the team and the community. One of the thoughts that occurred to me as we reflected on our own mistakes and developed our own learnings, was that other businesses and organizations might benefit if we shared our own process.

Within a few days after launch, we put a meeting on the calendar for the entire team: Lessons Learned. We decided that this meeting would not take place for a few weeks, because we knew that problems were still arising in those first weeks and we wanted to be able to discuss ALL of the issues and all of the consequences which were revealed. This was important, because it wasn’t immediately evident where some of the issues lay and we knew that, given enough time, they would be uncovered.

We structured this meeting in 3 parts: 1) identify pain points; 2) identify “themes”, and; 3) develop “lessons learned.” It was important to us to give the meeting a structure and this 3-part approach allowed us to focus on the process, but also to give everyone a voice and some ownership of the meeting itself. We set out some ground rules at the start: everything was fair game (meaning that nothing and no one would be exempt from critique); everyone was expected to contribute (we wanted to understand the different pain each individual experienced); and finally that accountability would be a focus. We determined that the best outcome would be to identify a small number (5 or 6?) important lessons and use these to inform and improve our process going forward.

We gathered in our conference room, which has two large whiteboards: 12 running feet of room for thinking. notation, and charting. First we agreed that we would break the process up into a chronological sequence of phases: planning, pre-launch, launch-day, and post-launch. We would look at each of our functional areas: management, software development, customer service, and marketing/PR. This framework allowed us to work our way thoroughly through the entire process and carefully evaluate actions performed during each of these phases. It hadn’t been planned a such, but this became an all-day process; several hours were spent working through the pain-points from each of the phases; another hour was spent identifying  thematic similarities. And finally, boiling these down to a handful of lessons learned took another couple of hours.

Pain-points: some interesting developments occurred during the “pain” part of the meeting. It became clear that the parts of the process that contained the greatest collective pain were the planning  and pre-launch phases. As we listed out the individual comments and points, we noticed themes beginning to emerge. We agreed that we would jot down notes on these, but circle back in the second part of the meeting. The board quickly started to fill as we went around the room talking about each individual’s and each department’s experience and perspective. It took a bit, but as we talked folks became more and more comfortable articulating mistakes we had each made and identifying our lapses and the consequences of those. A clear catharsis took hold as we voiced for one another how difficult the process had been.

Themes: these started to emerge quickly, with several becoming evident within the first 30 minutes. Communication problems (both internal and external) jumped out at us quickly. Transparency, quality issues, planning problems, and accountability were several no-brainers, But there were other less obvious themes, and we took the time to comb through the pain-points to reveal them.

Lessons learned: This was harder than we thought it would be. We needed to keep this to a manageable number, so as not to overwhelm ourselves going forward. These lessons needed to be a distillation of the themes we identified, much as the themes were a distillation of the pain-points. We ended up with nine lessons to take forward and apply to our process:

  • Keep eyes on the prize; don’t lose track of the big picture.
  • Improve communications: restructure regular meetings, remove firewalls, and improve the tools we use.
  • Do a better job defining project scope. Always try to reduce scope and simplify whatever we are building.
  • Implement faster and shorter iterative cycles.
  • Define production schedules early and be accountable for this.
  • Hold ourselves to high standards of quality and improve our own QA and testing regimens.
  • Be customer-centric: don’t lose track of who we are building products for and the impact our process will have on them.
  • Improve the quality of our leadership. Management needs to do a better job enabling. motivating, and communicating.
  • Be transparent internally and externally. Make sure that people stay in the loop and know what the other departments are doing.

Well, that’s it on our own post-mortem. The very act of this undertaking has helped to make us a better and stronger team and we hope this will extend to a better and stronger product and a more successful business. The time we spent examining our own process caused pain of it’s own: some deadlines extended, some customer service responses delayed, and some business opportunities put on hold for a day. But, the net result was incredibly useful to us, and if we allow these lessons to inform our process, they should go a long way to reducing the pain next time around.

I would love to hear from any of you who have been through similar efforts or have found good processes of your own for this exercise. In the meantime – happy dissecting of your own efforts!

Need something designed? Name your price. Pick from 110+ entries. Love it or your money back.

Like our blog? You’ll freaking love our Twitter updates. Oh, and you’ll dig our Facebook page too.

  • Pingback: Tweets that mention The post-mortem: how small businesses and startups can learn from their mistakes « crowdSPRING Blog -- Topsy.com

  • Stihl Chain Saw

    Hey, thanks so much for posting this original and unique article. I can’t tell you how many times I’ve visited blogs
    from Google and they’ve got nothing on them but crappy ads and false information that’s unereliable. I don’t
    normally comment on blogs, but I just thought that i’d drop you a line and tell you that I think you’re doing a fantastic job.
    Thanks!

  • Stihl Chain Saw

    Hey, thanks so much for posting this original and unique article. I can’t tell you how many times I’ve visited blogs
    from Google and they’ve got nothing on them but crappy ads and false information that’s unereliable. I don’t
    normally comment on blogs, but I just thought that i’d drop you a line and tell you that I think you’re doing a fantastic job.
    Thanks!

  • Robert

    I think the misconceptions is that a lot of people care on what
    crowdspring is doing; they don’t, not one bit.
    site loads faster tho. so good job. kudos for making a website that loads.

  • Robert

    I think the misconceptions is that a lot of people care on what
    crowdspring is doing; they don’t, not one bit.
    site loads faster tho. so good job. kudos for making a website that loads.

  • Tal

    Useful post, Mike. crowdSPRING’s refreshing transparency is one of the things that make be proud to work here.

  • Tal

    Useful post, Mike. crowdSPRING’s refreshing transparency is one of the things that make be proud to work here.

  • Bodo

    Hey, love the post. I think its very important to look back and learn. Am a communications student and I guess am getting to see more and more how important it is. You’re doing a great job. To be honest I haven’t participated in any project (design) of late, av been quite busy. I still think you guys are GREAT! Cheers.

  • Bodo

    Hey, love the post. I think its very important to look back and learn. Am a communications student and I guess am getting to see more and more how important it is. You’re doing a great job. To be honest I haven’t participated in any project (design) of late, av been quite busy. I still think you guys are GREAT! Cheers.

  • David

    Nice article. Kudos for your transparency.

    All companies, big and small, should learn from this classic article, before embarking on a major rewrite of their software:

    http://www.joelonsoftware.com/articles/fog0000000069.html

    Also, the lessons learned from your experience can all be found in SCRUM. Reinventing the wheel can break small companies.

  • David

    Nice article. Kudos for your transparency.

    All companies, big and small, should learn from this classic article, before embarking on a major rewrite of their software:

    http://www.joelonsoftware.com/articles/fog0000000069.html

    Also, the lessons learned from your experience can all be found in SCRUM. Reinventing the wheel can break small companies.

  • Paper Foxes

    Thanks for such a thorough explanation of your evaluation process. This is a great format for a launch post-mortem. I will definitely be sharing this with co-workers.

  • Paper Foxes

    Thanks for such a thorough explanation of your evaluation process. This is a great format for a launch post-mortem. I will definitely be sharing this with co-workers.

  • Mike

    Hey all – thanks much for your comments and feedback!
    @Stihl Chain Saw: Kind words, indeed; much appreciated!

    @Robert: ah, it’s true that blog posts like this one are not for everyone, but thanks for stopping by and thanks for using the site. Glad to hear that your experience is positive.

    @Tal: Graicas, amigo… we’re proud that transparency is one of our core values.

    @Bodo: Thanks much for visiting; we’re looking forward to getting you back as an active participant in the projects!

    @David: Scrum is a fantastic tool and we have our own version of this type of stand-up meeting that the entire team participates in on a daily basis (http://blog.crowdspring.com/2009/01/in-defense-of-meetings/). But larger scale meetings like the one I describe in the post are above and beyond the daily scrum.

    @Paper Foxes: Great to hear that your team can also learn and improve. Please let us know if you have any specific questions about our own process.

  • Mike

    Hey all – thanks much for your comments and feedback!
    @Stihl Chain Saw: Kind words, indeed; much appreciated!

    @Robert: ah, it’s true that blog posts like this one are not for everyone, but thanks for stopping by and thanks for using the site. Glad to hear that your experience is positive.

    @Tal: Graicas, amigo… we’re proud that transparency is one of our core values.

    @Bodo: Thanks much for visiting; we’re looking forward to getting you back as an active participant in the projects!

    @David: Scrum is a fantastic tool and we have our own version of this type of stand-up meeting that the entire team participates in on a daily basis (http://blog.crowdspring.com/2009/01/in-defense-of-meetings/). But larger scale meetings like the one I describe in the post are above and beyond the daily scrum.

    @Paper Foxes: Great to hear that your team can also learn and improve. Please let us know if you have any specific questions about our own process.

Hey, it's crowdSPRING!

Tens of thousands of the world's best and most successful entrepreneurs, businesses, agencies and nonprofits rely on crowdSPRING for affordable and risk-free custom logo design, web design, a new company name or other writing and design services. More than 162,000 designers and writers work on crowdSPRING. We create designs and names people love. 100% guaranteed.

Get Blog Updates

Free E-Books

12 Question Interviews with cS designers.
Get it »

Contracts for designers who hate contracts.
Get it »

Contracts for software developers who hate contracts. Get it »

More in Small business (326 of 481 articles)

/** chartbeat **/