From zero to launch in four months
Eight tips on launching software quickly.
A few years ago the company I was at (Spigit) decided to build and launch a new piece of software. This software would be a test-ground for companies thinking about using their full innovation platform, so it needed enough functionality to prove the value of upgrading. The product would be designed and built from scratch, and needed to be ready in time for a launch event in four months.
Sixteen weeks later- after a lot of coding, learning, iterating, tantrums and politics- Icon was ready.
I was the Product Manager responsible for delivering Icon. This is a summary of how we did it, with recommendations for others looking to iterate quickly and launch fast with a small team.
1. Be agile-ish
Spigit traditionally used the waterfall method of software development (briefly: write a requirements doc, pass it to Engineering, wait and see what comes out 6 months later). As we needed to be sure we’d have something to launch in 16 weeks, waterfall wasn’t going to work for Icon.
To help break the work in to chunks, get regular feedback, and quickly change direction if needed, we switched to agile-ish. I say agile-ish because we were new to this game, and a clean switch to textbook agile didn’t work for us. We had two-week sprints, user stories, standups and post-it notes. However, we also started with a long requirements overview document, had a Gantt chart running, and estimated in days rather than points.
If you need speed in your software development use agile, but don’t worry about sticking to the rules. Use the form of agile that works for you and amend over time.
We had a bumpy start but in the end agile worked well for our team. It gave us the chance to see the software working early on and to test it throughout, rather than getting a bug-filled surprise at the end.
For more on introducing agile to a team, check out this article:
2. Co-locate, or be very good at remote working
If you’re after speed, co-locate. And not just in the same office: the whole team should sit in the same room (with breakout spaces if needed). Walking across the hall might not seem a big deal but when you’re heads down with a tight deadline every shortcut helps.
If you have a remote team, be fair to them. Have the checkin at a time that works, use online systems for project tracking, and use video conferencing and chat clients.
Spigit’s HQ is in San Francisco but I lived in the UK when we started Icon. We didn’t do remote working well (post-it notes don’t work when you’re not in the office!). In the end I temporarily moved to San Francisco to get the software ready for launch.
When we had more time to breath I introduced online tools such as Pivotal Tracker and video conferencing. With these changes, the Icon team was able to work well together across the USA, UK, India and Bolivia.
3. Over-communicate
Keep everyone- the delivery team, customers, PR group, and employees- up to date with progress and what’s coming soon.
Do daily standups with the project team from the start of the project to make sure everyone’s up to date and there are no blockers. As it gets closer to launch do weekly then daily checkins with the wider, business-focused delivery team.
It may be tempting to go in to stealth mode to get the job done without interruptions, but when engineering resources are scarce everyone will want to know what‘s going on.
4. Start small, iterate later
Icon was not a Minimum Viable Product in the usual sense: we could have launched earlier with a much smaller feature set, but the software needed to be fully-featured enough to serve a specific purpose and to fit alongside Spigit’s other products.
That being said, we did cut a lot out and we did launch with a few obvious holes. For example, our landing page worked but didn’t meet the standards we’d set.
We were also realistic with our marketing approach: we made an intro video in-house and got creative with launch tactics. The character “Mr Icon” started appearing on social media and we sent Iconic donuts to potential customers.
5. Build in data access from the beginning
If you’re launching a new product, keep the feature set small but include some form of data access from the beginning. If you don’t, you have no idea how your product is doing and which areas need focus.
We launched Icon with only limited access to data: we had a nightly report and integrated Chartbeat. It quickly became clear that that wasn’t enough, so we revisited later to integrate with RJMetrics and Google Analytics. If I was building now I would use a tool like Mixpanel or Heap Analytics from the offset.
Having data at your fingertips gives you something concrete to fight your critics with- and there will be critics, both internally and externally.
Give the whole company access to site data if:
a. The data story is obvious;
b. You’re realistic with expectations;
c. Everyone is open about the progress of the app.
It’s great for everyone to care about how the project is doing, but incorrect assumptions and fire-drills caused by misinterpreting data don’t help the company.
6. Be wary of mobile-first
If you’re building software think carefully before optimising your MVP for mobile from the beginning.
We aimed high and decided to make Icon responsive, altering its design to suit the viewer’s screen size. This was the correct sentiment but it made the project much more complex as each screen had to be designed, implemented and tested in three slightly different ways.
Our target audience meant that mobile traffic was unlikely to be high enough to justify the extra development time. As long as the basic site worked on mobile we weren’t going to put many people off by not being optimised. Check out a great article on Mobile Second here.
While we’re on the topic of support: don’t even try to support all browser versions at first. We went for the latest versions of Chrome, Firefox, Safari and Internet Explorer. Each additional browser version (particularly the IEs) adds weeks of development time. The extra effort is unlikely to result in a large uptick in usage.
7. Be ready for the curveball
There will be a curveball. Expect it, resist it if you can, and if you have to absorb it make it clear that other things will be impacted.
In Icon’s case, we were given an additional requirement two weeks before launch. That requirement had a solid business driver so we went with it, prioritising it over other items that then didn’t make the cut as we had a hard deadline.
8. Celebrate small wins
If you’re iterating at speed it’s too easy to forget to pause and take stock of how far the team and software has come. Don’t forget to celebrate each small win.
The celebration and appreciation doesn’t need to be time-consuming or expensive. We had themed potlucks and game nights, welcomed family members to events and made sure that food was covered if the team was working late. Yammer used to do laptop stickers and floor decals. Microsoft did paving stones.
After four months of very hard work we launched on time with press releases, an “Icons do San Francisco” launch event and live demos at a partner conference.
In the first three months Icon had over 1000 companies sign up and won two awards. We kept iterating, changing both the software and the way we worked.
Check out the 90 second Icon video which gives a neat introduction to what we created.
A version of this article was originally posted on my personal blog.
