New End of Release Demo Process

Posted by

End of Release Blog Image
At Tasktop, we pride ourselves on not missing releases. We have not missed a release in over four years. And we release quarterly. That’s a pretty good record. As part of our releases, we hold internal release demos where the teams get to show off the new features they’ve added to the product. And we hold this end of release demo every 3 months without fail. There’s only one problem with the end of release demo…

It’s as boring as watching paint dry.

I cringe to say that because we have some whip-smart developers who can work miracles. But it’s true. Our end of release demos were rough. Part of it is how our product is built. We help companies solve business problems by providing integrations between their software development tools. We build connectors to a variety of ALM, PPM and QA tools and we build the integration engine that serves as the hub for these connectors. A large part of our demos were structured around supporting new artifacts (stories, defect, requirements, etc) or fields (text fields, single-select fields, multi-select fields, etc). After a few years of showing one field synchronized to another field, it gets a bit predictable.

In some ways, we’re a victim of our own success. When customers first see what we can do, they’re amazed, but we see behind the curtain and know how the sausage is made. I don’t need to see another single select field mapped to a string field. If you’ve seen this for one tool, it’s not a stretch to understand that it can be done with another tool.

Even engineering became bored with our demos. When the people showing off the new stuff get bored with how they’re showing it off, you know something has to be done.

So six months ago, we hatched a plan.

ONE UNIFIED DEMO

We decided to create one unified demo that shows how our new features solve an actual customer need. Instead of five development teams each presenting their own stand-alone demos that had nothing to do with each other, we would now have one unified demo across the entire engineering team. The Product team would be in charge of developing a demo story that could be told using the features developed in this release. Not all the team members would demo. And more importantly, not all the new features would be demo’d in the end of release demo. Some features may be too small or may not fit the demo scenario. Besides, we already record all the Sprint demos, so if you really need to see something in action, check out the team’s sprint demo.

What Happened

People loved it.

We’ve only gone through this twice, but it’s going great. The response from engineering as well as our other internal stakeholders was immediate and clear. We had glowing emails coming in within minutes of our first go with this new demo process.

Instead of the demo being a lot of disconnected standalone features, it became one comprehensive story. It also became much faster. Instead of taking the traditional 2.5 hours, we slimmed it to under an hour.

Most importantly it demonstrated to everyone that we make ONE SOLUTION that solves serious problems. We may have multiple products with various features, but at the end of the day, they are used together to help businesses deliver better software faster. Creating a demo story that explains to our stakeholders what customer problems we can solve today is incredibly powerful.

What’s Next
We have a few additional action items:

  1. Be more specific in pointing out the new stuff.
    Now that demos are a holistic story, they incorporate both existing and new features. We need to do a better job of pointing out in the demo “this is new functionality”.
  1. Start the process earlier.
    We can craft our demo story almost as soon as we finish our release plans. That gives the teams almost three months to prepare. That way, engineering will know from the very start of the release, what features will be presented at the end of the release.
  1. Shorten the scheduled time for the demo.
    After this most recent demo ended, the entire engineering organization looked around like, “what do we do now?” There was over an hour still on the schedule for demos. That was a holdover from our old process. We can now schedule other events and simply give people their time back.

It’s not every day you can give your organization over a person-week of time back, but we did it with this new demo process. Tasktop’s mission is to help companies deliver software better and faster, it only makes sense that we continue to strive to improve our own processes.