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.

Comments

  1. I don’t agree with “not telling anyone except your spouse”. I was trying hard to bring my product to 1.0, and it took like ages. First when I shared what I’m doing with my friends, colleagues and whole family I really started kicking me in the ass to finish the app asap.

  2. Bob Walsh says:

    That can work Michal, but IMO what’s more likely to happen is a) you talk out instead of code your great new idea b) There can be workplace repercussions.

  3. The best thing about constraints is that they give you a boundary that separates the good from the great. The truly innovative creator will find ways around constraints, especially technological and social constraints, and find ways to bring their groundbreaking ideas to market. I agree, constraints are a good thing for keeping projects within the realm of reality, but they are also meant to be pushed.

  4. Very interesting post.

    Constraints go with FOCUS, FOCUS, FOCUS, do not disperse, do not scatter, keep focus!