I get way too much spam in my inbox, even just counting things I've signed up for myself. Most of it I delete, but today's email from CoTweet stood out, and is worth mentioning. A while back I signed up for CoTweet, just to check it out -- nutshell: CoTweet lets you collaboratively monitor and manage multiple Twitter accounts -- but after my initial exploration I didn't go back to it. There may have been a reason, there may not have been. So, CoTweet, noticing my cold start, sent me an email, as any customer-aware and responsive web service should:
Subject: Is CoTweet for you? Hi Nick, We've noticed that no one has logged in to the @nickgrossman Twitter account through CoTweet lately. CoTweet is not for everyone. It's designed for teams who are managing the front-line of the real-time web for their organizations. .... No other tool allows you to engage customers one-on-one like CoTweet does. ....
They seem to have struck a nice balance between being self-promoting ("No other tool allows..."), while being self-aware and honest ("CoTweet is not for everyone"). In particular, I found the ordering of the argument to be effective. Here was my thought process:
Cotweet: "We've noticed that no one has logged in..." Me: "Yeah, yeah, I'm busy" (reaches to delete) CoTweet: "CoTweet is not for everyone" Me: "Ah nice, they're not trying to just straight up sell me. I appreciate that" CoTweet: "It's designed for teams who are managing the front-line of the real-time web for their organizations" Me: "Oh wait, that's me" (clicks sign in link)
So, thinking about my own work, there are two takeaways here: 1) make sure you follow up on cold starts (lord knows we don't do enough of this with some of our projects), and 2) when you do, phrase it in a way that's disarming, honest, and helpful. (looking forward to the email I get after I don't use it for another 3 weeks)
I spent most of this morning looking back through old posts about the Chandler Project and OSAF. I've thought about this a lot, due to the many parallels with my work at The Open Planning Project. For newcomers, those parallels are:
Massive funding from a visionary with a dream (in OSAF's case, Mitch Kapor, in TOPP's, Mark Gorton), where that dream may not always be perfectly articulated;
Rapid staffing around an open source project attempting to satisfy that dream (OSAF's Chandler to TOPP's OpenCore / OpenPlans
I get way too much spam in my inbox, even just counting things I've signed up for myself. Most of it I delete, but today's email from CoTweet stood out, and is worth mentioning. A while back I signed up for CoTweet, just to check it out -- nutshell: CoTweet lets you collaboratively monitor and manage multiple Twitter accounts -- but after my initial exploration I didn't go back to it. There may have been a reason, there may not have been. So, CoTweet, noticing my cold start, sent me an email, as any customer-aware and responsive web service should:
Subject: Is CoTweet for you? Hi Nick, We've noticed that no one has logged in to the @nickgrossman Twitter account through CoTweet lately. CoTweet is not for everyone. It's designed for teams who are managing the front-line of the real-time web for their organizations. .... No other tool allows you to engage customers one-on-one like CoTweet does. ....
They seem to have struck a nice balance between being self-promoting ("No other tool allows..."), while being self-aware and honest ("CoTweet is not for everyone"). In particular, I found the ordering of the argument to be effective. Here was my thought process:
Cotweet: "We've noticed that no one has logged in..." Me: "Yeah, yeah, I'm busy" (reaches to delete) CoTweet: "CoTweet is not for everyone" Me: "Ah nice, they're not trying to just straight up sell me. I appreciate that" CoTweet: "It's designed for teams who are managing the front-line of the real-time web for their organizations" Me: "Oh wait, that's me" (clicks sign in link)
So, thinking about my own work, there are two takeaways here: 1) make sure you follow up on cold starts (lord knows we don't do enough of this with some of our projects), and 2) when you do, phrase it in a way that's disarming, honest, and helpful. (looking forward to the email I get after I don't use it for another 3 weeks)
I spent most of this morning looking back through old posts about the Chandler Project and OSAF. I've thought about this a lot, due to the many parallels with my work at The Open Planning Project. For newcomers, those parallels are:
Massive funding from a visionary with a dream (in OSAF's case, Mitch Kapor, in TOPP's, Mark Gorton), where that dream may not always be perfectly articulated;
Rapid staffing around an open source project attempting to satisfy that dream (OSAF's Chandler to TOPP's OpenCore / OpenPlans
The Slow Hunch by Nick Grossman
Investing @ USV. Student of cities and the internet.
The Slow Hunch by Nick Grossman
Investing @ USV. Student of cities and the internet.
Due to both of the above, a propensity to expand scope and broaden the potential market(s).
Since Dreaming in Code (the book chronicling the story of Chandler and OSAF) was published in 2007, Kapor has stepped away from the project and pulled his funding. Through 2008, OSAF operated under his funding, but with a scaled down staff (10 down from ~25). Long story short, the project failed to get enough traction and was just too expensive. There has been lots of commentary about why this happened, so I'm not really attempting to describe anything new here. For my own understanding, though, I want to jot down the takeways that seem most relevant to my work at TOPP. Here's what it seems that OSAF couldn't do, and what I'm hoping to do at TOPP Labs: Choose one market to start with, and satisfy it fully. In Crossing the Chasm, Geoffrey Moore describes a (high tech) market as the following:
a set of actual or potential customers
for a given set of products or services
who have a common set of needs or wants, and
who reference each other when making a buying decision
According to Moore, it's the last one that tends to hang people up -- it's not a market unless the members reference each other. In other words, you need to focus. In his "beachhead" (aka D-Day) strategy, he advises putting your full effort into your initial market segment, generalization be damned, and satisfying other users with what's left over. If there aren't any real constraints, create some. If embrace change was the mantra of the XP movement, and embrace constraints is the mantra for web 2.0 startups, then perhaps introduce constraints to create change should be the mantra for over-funded tech non-profits. Some constraints that are particularly relevant in this case are: target market (see above), team size, project scope and timelines, and if all else fails, funding. Granted, it is difficult (but not impossible, IMO) to introduce other constraints when funding is plentiful and reliable. Don't get too academic, OR, let the market drive your decisionmaking. This is perhaps just an extension of "constraints", above, but I think it's worth mentioning separately. Looking at the way Things (team of 2 devs) and OmniFocus (experienced sofware entrepreneurs) ate Chandler's lunch, it's clear that there was a failure in the product development process. While the Chandler team was debating database infrastructures and making endless product spec notes in their wiki, Things brought a simple, usable product to 1.0 in just over a year. They didn't have the luxury of lengthy debates; they needed to get something out there, get people using it, and get feedback. Since their 1.0 release in January 2009, they've steadily released relevant updates based on real feedback. Can you be market-based and constrained in an open source environment? I think so; it just required leadership and understanding of these factors. It could be argued that Chandler wasn't able to implement these kinds of changes because of its open source nature and collaborative process, but I believe that it's possible (and this has been clearlydemonstrated) to maintain market focus and constraints in an open source project. So, now that we've got that straightened out, it should be smooth sailing, right?
Due to both of the above, a propensity to expand scope and broaden the potential market(s).
Since Dreaming in Code (the book chronicling the story of Chandler and OSAF) was published in 2007, Kapor has stepped away from the project and pulled his funding. Through 2008, OSAF operated under his funding, but with a scaled down staff (10 down from ~25). Long story short, the project failed to get enough traction and was just too expensive. There has been lots of commentary about why this happened, so I'm not really attempting to describe anything new here. For my own understanding, though, I want to jot down the takeways that seem most relevant to my work at TOPP. Here's what it seems that OSAF couldn't do, and what I'm hoping to do at TOPP Labs: Choose one market to start with, and satisfy it fully. In Crossing the Chasm, Geoffrey Moore describes a (high tech) market as the following:
a set of actual or potential customers
for a given set of products or services
who have a common set of needs or wants, and
who reference each other when making a buying decision
According to Moore, it's the last one that tends to hang people up -- it's not a market unless the members reference each other. In other words, you need to focus. In his "beachhead" (aka D-Day) strategy, he advises putting your full effort into your initial market segment, generalization be damned, and satisfying other users with what's left over. If there aren't any real constraints, create some. If embrace change was the mantra of the XP movement, and embrace constraints is the mantra for web 2.0 startups, then perhaps introduce constraints to create change should be the mantra for over-funded tech non-profits. Some constraints that are particularly relevant in this case are: target market (see above), team size, project scope and timelines, and if all else fails, funding. Granted, it is difficult (but not impossible, IMO) to introduce other constraints when funding is plentiful and reliable. Don't get too academic, OR, let the market drive your decisionmaking. This is perhaps just an extension of "constraints", above, but I think it's worth mentioning separately. Looking at the way Things (team of 2 devs) and OmniFocus (experienced sofware entrepreneurs) ate Chandler's lunch, it's clear that there was a failure in the product development process. While the Chandler team was debating database infrastructures and making endless product spec notes in their wiki, Things brought a simple, usable product to 1.0 in just over a year. They didn't have the luxury of lengthy debates; they needed to get something out there, get people using it, and get feedback. Since their 1.0 release in January 2009, they've steadily released relevant updates based on real feedback. Can you be market-based and constrained in an open source environment? I think so; it just required leadership and understanding of these factors. It could be argued that Chandler wasn't able to implement these kinds of changes because of its open source nature and collaborative process, but I believe that it's possible (and this has been clearlydemonstrated) to maintain market focus and constraints in an open source project. So, now that we've got that straightened out, it should be smooth sailing, right?
