Chandler and Constraints

• 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 clearly demonstrated) 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?

• 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 clearly demonstrated) 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?

>1.2K subscribers

>1.2K subscribers