So, we have the problem defined and have estimated that the project is a good one to do — if its profitable. So how successful will it be as a business? Nobody can reliably predict the future, but we can take a shot at it and see what we learn along the way.

The Fundamental Equations

• Profit = Revenue (Income) – Expenses
• Profit also = ( Margin * Number of Sales ) – Fixed Costs
• Revenue = (generally) Number of Sales * Sales Price
• Margin = Sales Price – Cost
• Cost = What you make of it
• Sales Price < Min( Value to the customer, Price of competitors with same value)
• Number of Sales = Number of potential customers * Conversion Rate

So let’s try to fill in some of these numbers.

Number of Potential Customers

The target audience for the immediate problem is bakeries that are having problems understanding and managing the costs of their ingredients. This suggests that they’re small bakeries with limited numbers of employees who would rather be baking than crunching numbers.

In Canada (as of 2001) there were 1,779 bakery establishments. I have one source that says there were 24,189 bakeries in the U.S. Europe and Latin America are potentially two good areas to find customers, but for now I’m going to concentrate on North America.

As of now, there are several unknowns that prevent me from calculating potential customer base:

• How many bakeries have this particular problem of cost management? I’m assuming that large ones already have systems in place to do this, and so are not potential customers. However, my Domain Expert (the friend who wants this application) says that it’s a large number of the smaller bakeries. She’s been an instructor in the industry for quite a while so I’ll have to defer to her statement for now.
• How many bakeries with this problem would be willing to use software (of any sort) to solve this problem? There’s some logistical problems here: namely that the people involved have to be willing and able to use a computer during their business operations. My Domain Expert says that this isn’t much of a problem; computers are integral for these types of business anyway.
• How many bakeries willing to use software would be willing to pay for it, at any price? You’d think that this would be “all of then”, and it should be if the software solves their problem, but some people seem to resist any sort of cash outlay they consider “unnecessary.” Hopefully this is a small factor.

It’s very easy to fall into the “All we need is X% of the total market to make $Y” trap. Usually this arises from someone coming up with a goal value for Y, deriving an X that amounts to a “small” value, and then assuming that X will be easy to achieve. But that’s not how business actually works: X is the independent variable here and it’s the one that you have to focus on; Y is a consequence of that.

More To Come

I want to keep these posts relatively short, so I’m cutting my analysis off here and saving the rest for another post.

Update: Some Numbers

I got some answers to my questions after I wrote this.

There is an infinite stream of problems to solve. However, finding one that’s worth working on is another matter entirely. Nothing comes for free, so we have to pick and choose what we focus on. Here’s some of the questions that I’ve asked during the course of my investigation.

The Ultimate Question: Should I Build This?

Q: Is this particular project worth my investment in time, effort, and money?

“Ultimate” has two connotations: last and most important. This question fits both of those; not only does it override everything else, but it’s only answerable after you resolve all of the underlying questions. However, it’s easy to lose sight of goals, so it needs to be asked first. This is where we can apply a fringe benefit of being a programmer: we’ll push it onto the stack and come back with an answer later. Asking this first gets us started though: it forces us to ask “How do we answer this particular question?”.

Benefits

Q: What do I get by working on this project?

Here’s my answers thusfar:

• Potential for profit. At first glance, this product looks like it should be able to make some money. More investigation needed here.
• Potential for huge profit. Actually, the chances of striking it rich selling to small bakeries seems pretty small. But stranger things have happened. This is a very minor (i.e.: unlikely) benefit but it’s nonzero.
• Potential for profit without spending lots of ongoing time. Everyone is limited in the amount of time they can spend on any given task. When you are directly converting time into money (which I do as a consultant) there’s a hard upper limit to the amount of money you can earn; all of your growth must come from increasing your per-hour rate, and eventually that will max out. Selling a product like this can circumvent that limit; the amount of money earned relates to the number of people who buy your product. This is potentially a much deeper pool than time. (Fun facts: there’s roughly 94,000 working hours in a lifetime, but 7 billion people on the planet right now.) See also: revenue per employee.
• Opportunity to learn new technologies. I can read all I want, but to actually know something I have to do something with it. Real-world projects give me the chance to solve real-world problems and get practical experience.
• Practice at building a business. Same as above, but outside of the technical realm.
• Helping a friend. Never a bad thing.
• Exposure to a new industry. New stuff to learn. New people to meet. New opportunities. One more basket in which to put eggs.
• Credibility and Reputation. I can say “I did this.” It’s action, and not just talk.
• Exposure. It’s good stuff to write about, and may get some good attention.
• Enjoyment. Building new stuff is fun. Having the results is fun. Making decisions is fun.

Costs

Q: What do I give by working on this project?

• Time. This will necessarily take away from other things I could be doing. Here’s a few: spending time with wife, family &amp friends, hobbies (photography, gaming, hiking), exercise.
• Opportunity Cost. Pretty much the same as “time”, but with a money angle to it. The time I spend on this project means that I’m not working on other projects I have on the backburner. The question becomes: which project has more benefits/profit potential? I think that this one is reasonably good.
• Ability to start a new project. Very similar to “opportunity cost” but specifically focused on an unknown future project that has a greater net reward. I don’t like starting projects that I don’t finish (though that happens far too often). This is more applicable to this project since it involves a friend.
• Effort. Building stuff often drains my personal energy, leaving less for other stuff. (See “Time”; it’s very closely related.)
• Money. This project should be pretty cheap in terms of actual cash outlay, but there may be some costs ahead of revenue. Right now I see graphic design and some hosting setup costs.
• Credibility and Reputation. There’s a downside here too. I’m not too worried about the fallout from the business failing, but there is potential for bad decisions and actions to negatively impact me.

Conclusions

A lot of this is incalculable, and thus hard to analyze. However, the costs seem to be quite manageable. Time is the biggest one, but it has to be spent somehow, and I think that investing it in something with a payout potential is worthwhile. There are some guaranteed intangible benefits.

As usual, the deciding factor is profitability, which is the next thing I’ll look at.

Pretty much all software is intended to solve a problem of some sort. The “problem” simply be “I want to be entertained”, but for “business” software it’s usually more specific. Ideally it’s tied to a profit-generating function. You’ll sometimes hear them referred to as “pain points”, “challenges”, “requirements”, or “opportunities”; they’re all really the same thing.

A few weeks ago I was approached by one of my wife’s friends. She’s opening a bakery here in Calgary and asked if I would be interested in creating some software for her. We met, discussed her needs, and I got a bit of understanding about her industry. From this I derived the major problem that I’ll focus on for the first round of development:

To be successful, low-volume / boutique bakers need to keep good control of their materials costs. However, it is difficult for them to do so, and so many do not.

This manifests itself in two ways:

1. Recipes are written to produce X number of finished units for Y ingredients. The bakery will require X*Z finished units per day, and so much put in Y*Z ingredients. However, if Z is not the values 2, 4, or 10, then calculating X*Z and Y*Z becomes relatively difficult and cumbersome. (The situation is made worse if you’re using non-metric units of measurement.) Instead, many bakers simply round up to the nearest easily-calculable value of Z, resulting in a lot of waste and expense.
2. To determine the per-unit cost of a product, you need to take:
   • The price of one purchasable container of each of your ingredients,
   • Divide that by the number of measured units in the container
   • Multiply that by the amount of ingredient in the recipe
   • Adjust (add) for waste and other miscellaneous uses
   • Repeat the above for every ingredient in the recipe
   • Sum the results for each ingredient together
   • Divide by the number of units in the recipe

   Repeat this process for every product sold (or potentially sold) in the business. Again, all this hoop-jumping means that bakers tend to not do this, and thus do not understand the costs of their products. Without knowing costs, you can’t know margin, profitability, efficiency, value, and opportunity.

Basically, the problem is one of mental math. Humans suck at it. Worse, they are often afraid of it, and so will go to lengths to avoid it. On the other hand, it’s basically the only thing that computers do, and they do it faster, cheaper, and more accurately than a human ever can.

This problem is well-suited to a technical solution: not only does it bridge a gap in human capability, but it’s one that’s extremely easy to build. (I basically just outlined the algorithm above). That means that it can be done without too much up-front investment in time and money. That’s important for determining whether it will make a viable business.

In addition to my “day job” as a software development consultant, I’m also evolving into a software entrepreneur. I want to sell products and not just my time. Over the past few years I’ve seen a lot of people accomplish the same dream (most famously the inspiring guys at 37signals). I’m going to try my hand at the same.

In concert with this, I’m going to document my development process, tasks, and ideas. I’m doing this for several reasons:

• To potentially inspire and instruct others to do likewise.
• To perhaps get some feedback from the development community.
• To document my processes for my own reference, benefit, and reflection.
• To build my cred by illustrating my thoughts and capabilities. (Better to show than simply to claim.)

I hope to go into a fair amount of detail — hence the “Play-By-Play” tag and title I’ll be applying to each of my posts. Please comment freely and enjoy!

Ted says: Clients don’t always say what they mean. This is 100% true. My experience is that the majority of all people in business can’t fully and clearly articulate their thoughts, either verbally or in writing. Compounding this are situations where the client isn’t 100% honest and forthcoming; these run the range from simple cautiousness to outright deceit. Thus, you typically can’t take a client’s statement at face value.

Furthermore, even if a client can say what they mean, they may not mean what they actually want. And, even if they mean what they want, they may not actually want what they need. It’s the need that should be fulfilled, but there’s a lot of obstacles in the way.

To make matters worse, these obstacles are often multiplied by the numerous layers of “clients” involved. Here’s an example based off a real-world situation (the one I was in until recently):

1. The implementor gets requirements from his immediate boss.
2. The boss gets the requirements from the business/marketing/client relations department.
3. The client relations department gets their requirements from a 3rd-party development company (who is subcontracting part of the work to the implementor’s company)
4. The contracting development company gets their requirements from the actual client.
5. The client gets their requirements from the users.

It’s easy to see how confusion and misinformation can affect the requirements when there’s this many stages between the producer and the consumer of a piece of software. That’s why it’s important to do a thorough review of a particular request to verify that the sights haven’t drifted too far off the target.

I like mining as metaphor. There’s a nugget of gold buried in a mountain of communication. You need to dig away all of the useless rock in order to find it. As you dig, you’d better be setting up struts of solid reasoning to keep it from collapsing on you… and you’d better be digging in the right direction, or else you might miss the prize entirely.

Bruce responds to my prior post on requirements:

…I think you also have misinterpreted the user’s statement of the requirement.

Ted’s discarded first sentence IS a problem statement, but only for the second sentence (password confirmation field).

I don’t think the last sentence is a goal for the two requirements, in fact it has got nothing to do with problem statement. Interpreting it as the goal causes your question 5 to yield a negative answer.

The last sentence is (I think) a statement of a second problem, which leads to the second (but already stated) requirement. I would interpret the paragraph (briefly) as…

I didn’t really put any interpretation into the validity of the first and fourth sentences, nor did I attempt to answer any of the questions I asked. I just used them to illustrate the questions & types of statements themselves.

However, Bruce’s disagreement shows exactly the kind of process I was looking for when assigning qualifiers and questions to the sentences in the first place. He brings up valid points which prompt further action:

1. acceptance (if everyone on the team is convinced he’s right)
2. counterargument (if someone on the team thinks he’s wrong and can explain why), or
3. clarification (go back to the requirement writers and ask for more information to confirm or deny the assumptions we’ve made

The last two actions restart the process until full agreement is achieved. If you have enough people with good reasoning skills and tenacity to see disagreements through until they’re resolved, then the results of your analysis will probably be very close to the hypothetical “most correct answer possible.”

Along the way, all of your requirements, problem statements, and goals stand a good chance of complete replacement. That’s a good thing — if you’re doing the wrong thing, it doesn’t matter how well you do it, you’ll still come out with a poor result.

Something happened to my WordPress install which caused the site to stall. A week of bickering with Dreamhost got me nowhere, but I reinstalled WordPress and now it seems to be working just fine. If you see any errors please let me know.

I’m signing up for Technorati. On one of the configuration pages I see this:

Quick Claim

What is it?

It’s quick! Just enter the username and password for your blog. This information will only be used to verify that you own the blog, and it won’t be shared or stored.

Dear lord, who are they kidding?

In any case, they do offer a sane alternative:

Technorati Profile

WordPress is a pretty impressive piece of web software. It’s pretty easy to use and has a lot of nice AJAX-y features. The WYSIWYG post editor is nifty although a little troublesome where it comes to paragraph and headline formatting (it reminds me a lot of Microsoft Word in that regard).

By far the most impressive feature though is the post preview window. Click the image below for some Hofstadtery goodness:

It shows you how your post will appear on your site, using the theme you have installed. That’s a pretty piece of web programming.

I remember doing a “corporate preview” page for my previous company. Basically all we did was recursively call the rendering engine from the target page, regex the hyperlinks into dead underlines, and spit it out. It worked, but it was mighty ugly, and the HTML it generated would make your eyes bleed. Times have changed.