Following on my previous product marketing post (PM 101, PM 102 PM 103) here is a great post from Mitch Kapor on several usefull product architecture patterns (buid from Tim O'Reilly talks about design patterns for innovation. Here is a summary of his Etech talk, and here (5 MB PDF) are the slides from his presentation at the Eclipse conference).
All those patterns apply to product marketing, and how products/services should be design in a web2.0 world.
Design for participation:
..Architect your service in such a way as to be used easily as a component of a larger system. Keep it modular, document your interfaces, and use a license that doesn’t hinder recombination.
User-centred development:
..Share your development efforts and processes with your users. Therefore release early and often. Set up mechanisms for user feedback, bug reports and patch contribution.
Syndicated e-commerce:
On today’s web you no longer need to build or own all the components of your application. Glue together the small pieces of others and repeat the design for participation pattern. Don’t close it up...
The Perpetual Beta:
Don’t package up new features into monolithic releases: rather, fold them in on a regular basis. Eg. Flickr, Google’s often very rich new features, deli.icio.us.. So if you’re not already thinking this way: operate as if you’re in perpetual beta.
Users add value to shared data:
The key to competitive advantage in networked applications is the extent to which users augment your data with their own. Therefore architect for participation beyond design and development: invite your users – both implicitly and explicitly – to add value. You can gain a lock-in, and it’s not a hostile lock-in.
Network effects by default:
Only a small percentage of users will go to the trouble of explicitly adding value. According to Clay Shirky, there are three ways of building a database: you pay someone, you get volunteers to do it (Wikipedia) and Napster showed us a third way. You architect a system where users build it through, if you like, their own selfish activities. Aggregate the data as a side effect.
The Long Tail:
Many of the limiting factors from the physical world are absent on the internet. Therefore use the power of the computer to monetise niches formerly too small to be commercial. Find the long tail in your own – or someone else’s! – business. Google Adsense figured out you could monetise all these too-small-for-usual-advertisers pages..
Software above the level of a single device:
The PC is no longer the only access point for networked applications. Therefore design your application from the get-go to integrate services and share data across desktop, mobile and services.
Social networking:
Social networks are a by-product of social applications like email, IM, photo sharing, even book buying. Social networks are a by-product of social applications. We need to bake this stuff into our social applications instead. Architect your application to capture and share the social fabric underlying your application.
Data is the next “intel inside”.
Applications are increasingly data-driven. Look at Google Maps: map data is copyright Navteq and TeleAtlas. They’re the intel-inside of these cool apps.
Packets and shipping containers
As demonstrated by container shipping, IP packages and HTML pages a standard content-agnostic packet is the most effective way to ship both goods and data. Therefore understand the optimum “packet size” for your application domain and devise products that fit it.
Remix:
When content is digital it lends itself to being broken down and remixed. Therefore build your business model so as to make your living from the smallest atomic unit. The music industry made its money from the 10 or so crap songs on a CD rather than the one or two really good songs..
Comments