In January 2012 Spigit– the company that I work for- decided to build and launch a free product which would provide a testing ground for companies thinking about introducing a full innovation platform. The platform needed enough functionality to prove the value of company-wide ideation, would be designed and built from scratch, and- oh yes- it needed to be ready in time for a joint Yammer/ Spigit launch event in just 4 months. 16 weeks later- after a lot of coding, learning, iterating, tantrums and politics- Icon was ready. I was the Product Manager responsible for delivering Icon, and below is a summary of how we did it with some recommendations for others looking to iterate quickly and launch fast with a small team.
Spigit has traditionally used the waterfall method of software development (briefly: write a requirements doc, pass it to Engineering, see what comes out 3 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 2 week sprints, user stories and post-it notes, but 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. Even with a bumpy start agile worked well for us, giving us the chance to see things working early on and to test the software throughout rather than getting a big bug-filled surprise at the end.
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 thing but when you’re heads down with a tight deadline every shortcut helps.
If you have to have remote resources, be fair to them- have the checkin at a time that works, use online systems for project tracking, and use Skype and chat clients. Spigit is based in San Francisco but I was based in the UK when we started Icon and we didn’t do the remote thing 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 launch complete. Since then we’ve had the time to introduce online tools such as Pivotal Tracker and as a result remote working has become much more feasible. The Icon team is now based in the USA, UK, India and Bolivia
Keep everyone (the delivery team, customers, PR organisation, and employees) up to date with progress and what’s coming around the corner. Do daily checkins with the project team from the start of the project (to make sure everyone’s up to date and there are no blockers), and 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 if your company is small-to-medium sized and has multiple projects going on (as Spigit did) everyone will want to know what the scarce resources are doing.
After launch, give your company access to site data (e.g. number of signups) but only if the data story is obvious, you’re realistic with expectations, and 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 firedrills caused by misinterpreting data don’t help anyone.
Start small, but remember data is king
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 our “beautiful and award-winning” target, and access to data was limited. We did build a nightly report in to the product- but it quickly became clear that that wasn’t enough (we revisited later to integrate with RJMetrics).
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. Having data at your fingertips also gives you something concrete to fight your critics with (and there will be critics- both internally and externally. See “Everyone is not a product manager“).
… and mobile is not king (unless you’re building a mobile app)
With MVPs in mind, if you’re building a website don’t optimise for mobile when you first start out. We aimed high and decided to make the site “dance on demand,” altering its design to suit the viewer’s screen size. This was absolutely the correct sentiment- but it’s not so good in reality when resources are limited and each new screen has to be designed and implemented in three slightly different ways. Mobile traffic is unlikely to be high enough to justify the extra development time, and as long as the basic site works on mobile you won’t put many people off by not being optimised. Check out a great article on Mobile Second here.
And 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, and later added IE8 (because Windows XP users can’t use IE9… grr). Each additional browser version (particularly the IEs) adds weeks of development time- weeks that are unlikely to result in a large uptick in usage.
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. It certainly caused some panic at first though.
After 4 months of very hard work we launched on time with press releases, an “Icons do San Francisco” session and live demos at Yammer’s customer conference. In the first 3 months Icon had over 1000 companies sign up and won two awards. We’ve kept iterating since then, and have changed both the software and the way we work. Further details to follow in a future post- for now, check out the 70 second Icon video which gives a neat introduction to what we created or sign up and give it a go yourself. And feel free to get in touch if you’re interested in finding out more about our experience.