Developing - Aug 13, 2008 9:06 - 4 Comments

Constraints are a good thing.

Something I’ve noticed working with a fair number of microISVs and startups: constraints are a good thing.

The digital entrepreneurs who’ve been successful and therefore have the luxury of time and money are the those less likely to get to the point of releasing a new product.

Another version of this is the developer who wants to do a microISV, but is overwhelmed by all the possible kinds of software they can create, all the possible markets they could sell to, all the possible programming languages and frameworks they could use. They get lost in a hall of Internet mirrors.

Constraints give you a structure you can create in. Whether you code, write poetry or design web sites, constraints make things work and make you work to a higher level.

The trick in this business is realizing you no longer have a Manager to set constraints on you therefore you are free to pick and choose your constraints. That’s the good news. The bad news is you’d need to think about what those restraints on what you are going to do will be and commit to them before you lose focus.

Here’s five constraints you need to think about and make decisions on:

Time. This is the biggie. Unless you are working against a deadline, set X number of hours a week to work on creating your product, then work those hours and stop. Three good things happen with this approach:

• You are much less likely to meander down trivial features just because you can and because it is fun (or at least what we programmers think is fun).
• It forces you to get something working. It might not be the absolutely best in all the world solution, but it works and that above all else is the criteria for judging code, IMO.
• It forces you to make productive choices.

Money. Money is time’s evil twin if you’re not working for someone else on salary. You need to be very hard-headed about how much current income reduction you can tolerate in order to free up time for development. And, while development itself is free or nearly free, the things around development such as online backup service, custom art/web design and legal necessities such as accounting cost money: budget these and other expenses in advance rather than running short.

People. This is a two-parter: are you going to build a one-person microISV or join forces with other people to do a full-fledged startup in the traditional sense? Second part: who do you tell? Partnering brings to the table its own share of rewards, risks and to-do’s: there is no right answer here.

Regarding telling people, my advice is be conservative about who you tell and when. I don’t recommend telling anyone except your spouse until you know damn well you are going to have a product. And thereafter, be cautious. There will come a time and place to start talking about whatever your Project X is: at the beginning is not that time.

Features. Developers love to develop, that’s a big part of why we do what we do. But working for yourself means you’ve got to be as tough as the toughest boss you’ve ever had and ruthlessly par the not must have day one features away. Your goal, your only goal, is those features that make what you hope to sell worth the price you hope to get in your customer’s eyes. Everything else is a nice to have.

Case in point, I have a slew of features I wanted to have in the first release of Project X, but because they’re not core value features, they are going to wait until I (hopefully) release the next major build after the initial build. Some of these features were among the first ideas I had for this product and that most excited me at the beginning; but they are not the features the people I hope will become customers (you) will be most excited by.

Technology. It’s so hard to resist the siren call: should I have a iPhone interface on day 1? Oh look, there’s a cool jQuery-based grid! What about AIR, what about Siverlight, and on and on. If one of your full time jobs as a startup is tracking new technology that can have an immense effect on the app you’re building, another full time job is saying no to all but the tech that is going to be worth the time/money investment because it will generate revenue. In other words, prioritize adoption by revenue. IPhone interface? Nice to have, not for 1.0.

There are lots of other potential constraints out there - and that’s a good thing, they will help you get the job done. The trick is being proactive and defining as much as you are able to what you want those constraints to be.

Popularity: 70% [?]

More In Developing

• When the going gets tough, the tough get agile.
  Monday, July 28, 2008 17:51 - 3 Comments
• Silverlight for MicroISVs
  Friday, March 14, 2008 15:32 - 3 Comments
• The Top 6 MicroISV Design Mistakes
  Tuesday, February 19, 2008 9:50 - 1 Comment
• Deciding what goes into your microISV product
  Thursday, December 6, 2007 10:21 - 1 Comment
• Process and the mISV
  Friday, October 19, 2007 7:15 - 2 Comments

Business Practices Developing How to