I was reading Dion Hinchcliff’s “50 Essential Strategies for Creating a Successful Web 2.0 Product” (you should go read it when you have more time) and I’ve cherry-picked the points that ring true for me. His points are good and very interesting, but some are real gems of wisdom[1]. And I’ll add some of my own observations to this article. I’ll limit mine to 10 and if you’re ambitious you can read the 50 in his blog. One of the overarching principles is that, as he says, “The Web Community Gets Smarter Every Time It Builds A Product” – which I will exend to add that we marketers and developers are constantly learning, and the more we involve people early in our development processes, and the more closely we listen to them, the faster and better our development cycles will be.
Sky’s top 10 of Dion’s 50 Essentials:
[Dion’s #1] Start with a simple problem. [Sky says] Pick a problem that you can get your hands around. Don’t shoot so high that it will take you a year to build out a solution. For example, my mixed-reality games run on a complex Java-based infrastructure, but I can develop a new game by programming a scenario in a few hours.
- [Dion #2] Create prototypes as early as possible. [Sky says] It’s so much easier to create a prototype – and then throw it away if it doesn’t get used by the customes – than to spend a year creating a full-blown product, another year promoting it, and then throw it away.
- [Dion #3] Get people on the network to work with the product prototype rapidly and often. [Sky] Just a comment. This is sometimes the most difficult thing to do. I tend to work kind of on the edge and sometimes it‘s even difficult to explain what the prototype is or does…but that‘s the point…if I can‘t explain it and nobody uses it, I’d better find out about that early in the process.
- [Dion #7] Put off irreversible architecture and product design decisions as long as possible. [Sky] I phrase this one as “don’t rule out your options too early in the process.” What I mean is, when you build your first architecture, keep it open and flexible so you rule out as few options as possible in the future.
- [Dion #8] Choose the technologies later and think carefully about what your product will do first. [Sky] And this is probably the hardest one! I find that even though I’m supposedly the tech geek in the crowd, my marketing people are the ones who glom onto some tech or other (right now it is JavaFX) and decide that we simply must develop some online application that uses this or that other technology. This makes the solution fit the technology, not the problem! You fill in the rest…
- [Dion #10] Balance programmer productivity with operational costs. [Sky] And I will add another concern to this, which is that it is “far easier to conceptualize a product than to build it.” So, when we sit down and brainstorm, we can in 2 hours come up with a project that will take 6 months to implement. Easily. And then someone gets their head out of whack because they thought the product should have been ready next week. Dion’s point is that operation may take every bit as much effort as implementation, and in fact I would argue that almost always the operation of a product takes many times the effort of its development.
- [Dion #12] Plan for testing to be a larger part of software development process than non-Web applications. [Sky] Testing is huge. And people who’ve never tested a Web product before will always underestimate it. We test on four operating systems [Windows, Mac OSX, Linux, and smartphones], and we test the MS Internet Explorer, Firefox, Safari and Flock browsers (not on all platforms). This means that testing takes several times longer than you might expect.
[Dion #14] Have an open source strategy. [Sky] I’m going on a tangent here, but I want to add “have a creative commons strategy.” Open source is good, and it opens up the software source code for others to improve and use. But, in addition, and where possible, you should also open up the intellectual property of your product, making it available for re-use, expansion and elaboration. My nonprofit work is usually offered under a Creative Common by-nc-sa license.
- [Dion #15] Consider mobile users as important as your regular browser customers. [Sky] That’s only a little bit ahead of the curve. It’s coming soon. By the end of 2009, for sure. Plan and implement for the small screen, for limited tactile input (keyboards, touch, pointing and clicking), and for different types of interaction. For instance, quick back-and-forth is typical of phone-based interactions (such as TXT), but not necessarily of online interactions (such as email). Another example is that we’ve provided a relay of Daily Good from Charity Focus to cell phones for several years now – what we do is scrape a news feed they provide, once a day, and we pick off an XML item if it’s short enough to go to phones, and we relay it. (We also relay the entire item by email to those who prefer, and many of these email users are on mobile devices.)
- [Dion #18] Offer an open API so that your Web application can be extended by partners around the world. [Sky] Yessss! I use feeds from all over the place, including RSS news feeds from other blogs in my blogs, and I provide feeds for those who want to stay up-to-date with the information on my sites. These interfaces can be used by other web sites as well. For example, we provide an API for our knowledgebase (for searching and inserting – authenticated or not), and we provide a feed for our events page.
[1] I actually keep a file, and it’s over 10 years old now, named Gems of Wisdom, that contains all of the helpful little programming tricks and server administration tricks, that I’ve learned over that time.
Leave a Reply