Why Feature Spec Lists Should Be a Thing of the Past – 352 Noodles & Doodles

In years past, most of our projects were done with meticulous planning and rigid documentation. Like most of the web development world – any many other industries, from construction to manufacturing – our projects were ruled by Feature Specs and Project Documentation. One of the core reasons behind our switch to an agile web development methodology was that we no longer believed that rigid project documentation was the best way to deliver innovate, cutting-edge projects.

In fact, we hated it. We learned a while ago that change in a project is a very natural, beneficial part of any project, and we wanted both our clients and our development teams to have the freedom to encourage and apply change during development. In today’s 352 Noodles & Doodles, Geoff Wilson, 352 founder and president, will show you why innovation and iteration will trump feature specs for every project, no matter what field you’re in.

Transcript below.

Image credit: UK Department for Communities and Local Government

[Geoff Wilson]: 
Hi, I’m Geoff, and I’m the founder and president of 352, and I’m here today to tell you why feature specs and product documentation are a thing of the past. You see, like many companies, we used to create these really detailed project specifications whenever a project began. You know whether you’re creating a website or software like we do, or whether you’re doing construction or creating a medical device or whatever your field or industry might be the traditional way of thinking was whenever you go into any project you would plan it all meticulously in advance. You would create these detailed specifications of what was going to be done.
But what we’ve come to learn is that allowing for change is a very natural and, in fact, a very beneficial part of any project. It’s really all about innovation and iteration. Projects where you build in the capacity to innovate and iterate during the project are going to end up better. And, what we tell our clients now is that we actually don’t want to create a detailed specification at the beginning of a project.
 
The reason why is because if the client and the salesperson on our end sit down maybe with a technical architect and create this really detailed spec and then hand it off to a project team to actually build, you’re limiting the ability for that project team to come up with innovative ideas and to effect the project in a positive manner. You’re really limiting your project team’s creativity.
 
The better way to work is to create instead a loose concept an overall kind of epic idea of what you want to accomplish. Talk about goals. Tell stories. And then hand it off to the project team and allow the project team to innovate, allow them to come up with ideas and allow them to bring great new ideas to the table and allow them to work with you to make everything better. Working in an agile process such as what we do, every couple of weeks you have these sprint periods and every couple of weeks during the project the team gets back together with the client, reviews everything that’s been done, and again infuses more ideas into what can be done next.
 
So we encourage the project to kind of take a little bit of a wandering path as you go through the week of a project. Where you think you’re going to end up at the beginning of the project may not be where you end up at the end of the project. But because you have allowed the team to innovate and you’ve allowed iteration as part of the project plan, you plan for iteration. You plan for iteration and where you end up is going to be is going to be a much more beautiful, wonderful outcome than where you thought you could possibly end up when you were creating that project plan in the very beginning.
 
The other beautiful thing about working in an agile format, encouraging innovation and encouraging iteration and not creating those detailed project specs is that it also allows you to get an MVP – minimum viable product to market quickly. There is a whole startup movement, the Lean startup movement about how startups can succeed by getting a product to market quickly and then allowing people to start using that product and then to innovate on the product.
 
Companies in today’s day and age with technological change coming at us so fast, companies that win are companies that build a product and get it to market quickly. It’s not the most perfect product, it’s not the final version of the product, but they build it and they get it into consumers hands quickly. They watch how consumers are using it, how they are reacting to it, what they like, what they don’t like.
 
They get ideas from the actual end users and they build that into the next release cycle and they have lots and lots of quick release cycles for their product. That is how they win. 
 
Companies that are losing today are working in the old mindset that I’m going to spec out this massively complex project and we’re going to work in development to build this spec out in the next year to two years and then we’re going to get this product to market. That is no longer the way to be successful whether you are doing a web venture or any other type of venture.
 
I can tell you from personal experience why this is so important. I’ve been involved in two startups, two different startups that my wife and I started together. The first was a concept we came up with called Camp Pete. Camp Pete was an online virtual football world for kids.
 
If you have kids you may have heard of Club Penguin, Webkins, they are these interactive online games where kids create characters and they interact with each other in this online world. We decided to come out with a sports-themed one.
 
This was about five years ago when Club Penguin had just been bought by Disney and this whole field was just starting to heat up and, at that time, there wasn’t a good sports-themed one. So, we dreamed up this incredibly detailed concept for this online game called Camp Pete.
 
The reason why it’s called Camp Pete, by the way, is that we got Pete Carroll, who is currently the coach of the Seattle Seahawks, to sponsor the game. He was involved in the game and he got a cut of the game for partnering with us in it.
 
He was excited about the project. And we created this incredibly detailed spec – exactly what I’m telling you not to do. We spent tons of time on this laborious spec and we gave it to our development team at 352, and we had one of 352’s development teams just work on this incredibly massive world for a year and a half.
 It took us a year and a half to get it to market because the thing was amazingly complex. It had 15 games. It had over 70 scenes where kids could interact with each other. It had hours and hours of video. I mean, this thing was unbelievably massive and we got it to market and when we got it to market, we realized we had completely missed the mark.
 
The things that we thought kids using the game would love, they didn’t really seem to care about. The things that we didn’t think anyone would really care that much about, and we put very minimal time in, turned out to be our most popular features.
 
 The problem was, we took so long to get to market, that we burned through so much of our budget, that we no longer had much budget left to make the changes that would really be necessary to make the game a success. On top of that, because we were so long to get to market, during that time, several other virtual worlds emerged online, including sports-themed ones. So, by the time we got to market, it was no longer a novel concept either. 
 
Now, had we instead taken the approach of building that minimal viable product and getting it to market quickly, the business could have become a big success. What we should have done was just build a couple of scenes; just build one or tw
o games and get it out there quickly. Be first to market and let people start playing it, get the user feedback and then continue to innovate and iterate.
 
So when my wife and I started a second startup a few years ago, that’s exactly what we did. We started a startup called SocialNewsDesk. It’s an online social media management platform for television newsrooms. We started this, we limited our budget and we said, “You know what, we’re only going to do a couple months of development, and we’re gonna get this out in the hands of users. We’re gonna get some people to beta test it, and we’re going to try to sell it and see what happens.” And that’s exactly what we did.
 
The first version of SocialNewsDesk was really nothing to be proud of. It was fairly simplistic, but it was still unique. When we got this in the hands of our users, they said, “This has a little way to go, but we see the possibilities here.” And we convinced a few clients to come on board and start paying for the service.”
 
Then we felt much more enthusiastic about putting a little more money into it, creating the next release and getting the next release to market quickly. All of a sudden, we’ve got a few more customers, we’ve got some more great user feedback. We put a little more money into it. We got the next release to market quickly. We were constantly innovating, constantly iterating, and we were getting those releases to market quickly.
 
Fast forward a couple of years, and more than 85% of the television broadcast stations in the US now post to social media using SocialNewsDesk. It’s been incredibly successful for us, and I’m convinced that one of the primary reasons for our success is because we used a method, not of creating detailed project documentation, but rather, innovating and iterating and allowing ourselves to be flexible and building change in the process to get that minimal viable product to market quickly.
Ultimately that’s what it’s all about: launch quickly and iterate. Whether you’re doing a website, a software project or any other type of venture: launch quickly and innovate, iterate. Plan that into your process, and you will have far greater success. Thank you.