It isn't all about the code?
This is the coneblog journal and related categorized archives. You can read the blog as written back to front, or browse the categorized archives at right - check out the about categories for guidance on that is where. For a quick overview of the types of content you might run into, check out the Best of coneblog - some of my personal favorites.
Entries in Best of coneblog (24)
7 Web 2.0 Lessons from Adam Nash at LinkedIn
At a lecture by Adam Nash, Director of Product at LinkedIn, I got some insight into what makes a successful Web 2.0 venture. I have divided his comments and concepts into seven lessons for the Web 2.0 entrepreneur, with my personal embellishments:
- Understand your target market: Know your users and your demographic. It’s not what you think is cool, but what they think is cool. And if they is everybody, and you don’t have $50m to reach them, segment the market;
- Don’t wait: Don’t wait until you product is perfect, get it out there, experiment, and get some real market feedback. The best antidote for Eight Guys in a Room syndrome.
- It is all about Distribution: If you build it, they won’t come. Unless they see you as a natural progression from something they are already doing. That last sentence includes See – they must see you, and Progression – must be new, but connected. Almost no one can afford to create distribution on their own, so think about how you can leverage existing networks, sites, and communities. From the outside, the excitement over Facebook and OpenSocial is about distribution.
- Order is important: the path to web success is a sequence of problems and solutions. The order that you take them is important. Don’t obsess over your shopping cart UI until you have users who want to buy. Think about what comes first.
- Timing is important: you can have the right idea, and the right implementation, but be too early or too late. LinkedIn was almost too early – business professionals in the broader market weren’t ready to network on the internet. But some key industries and cites were, which created critical mass.
- It is a platform business: At the core, the value in your business is the value in your product platform: its features, robustness, agility. Its not the Brand. Seth Godin points out that Brand is a weak substitute for customer relationships. In a quickly moving web 2.0 world, your brand is only as good as your ability to service the needs and wants of your customers. Those needs and wants are fickle. A platform focus allows agility, collaboration, openness. From the inside, the excitement over Facebook and OpenSocial is about platform. Adam must be an old school developer, because he believes, as I do, that value in platform is all about your data model.
- Keep coding: Someone asked, how do I keep The Big Players from stealing my great idea. Adam suggested that you had to keep making your product better. I’ll paraphrase Thomas Edison, and say that success is ten percent idea and ninety percent code. Make a great product, then keep making it better.
Witness to a Barn Raising
What can the Amish tell us about working together? I watched an Amish barn raising last night, and reflected…
I was way behind in my laundry, so last night was designated Laundry night. In between running up and down the stairs, and some picture hanging, I watched the Harrison Ford movie “Witness”. It’s an excellent drama set in Philadelphia (my home town) and the nearby Amish Country.
What I Believe...
I recently re-screened that best of all Baseball moveis, "Bull Durham", and was inspired by "Crash" Davis' famous monoluge to write one of my own. So, with apologies to Kevin Costner, Susan Sarandon, and writer/director Shelton, here is What I Believe...
In those turning moments, be silent
Did you ever have one of those moments in a project where everything stops, there is a breathless pause, and the world starts to turn in a new direction? I had one yesterday…
A Brief History of Change –If a Need is Voiced by A User…
And no systems analyst is there to hear it and document it, does it represent a valid requirement? Like trees falling in the forest, this might seem like a frivolous question, but it gets at some important Requirements issues.