How and where to start a project

1. Say the idea in one sentence, and who it is for

Most projects do not die from bad execution. They die because nobody ever wrote down, in one sentence, what the thing does and who it is for. If you cannot say it in one breath, you do not have an idea yet, you have a mood. Write the sentence before you write anything else: a [thing] that helps [a specific person] do [a specific outcome].

"An app for productivity" is a mood. "A tool that lets a solo freelancer send an invoice in under a minute" is an idea. The difference is not length, it is specificity. A vague sentence lets you avoid every hard decision that follows it; a specific one forces them early, while they are still cheap to change.

The audience half of the sentence matters as much as the feature half. "Anyone who wants to be more productive" is not an audience, it is a wish. Name one real person: a role, a habit, a frustration you can picture. If you cannot picture who is annoyed enough by the current situation to try your thing, you do not know who you are building for yet, and every decision after this one is a guess dressed up as a plan.

2. Name the smallest version that would still be useful

Once you have the sentence, ask a harder question: what is the smallest version of that sentence a real person could use and get something out of? Not the smallest slice of the full dream, the full dream cut down to nearly nothing. The smallest version that stands on its own as something useful, even if it does almost nothing else.

This is the actual definition of a minimum viable product, and it is narrower than most people assume. Eric Ries, who coined the term, defines it as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."¹ The point was never to ship something half-built. It was to ship the smallest real thing fast enough to actually learn from it.

Consultant Henrik Kniberg's well-known version of the same idea is a sequence of vehicles: a skateboard, then a bicycle, then a motorcycle, then a car, each one a complete, ridable thing on its own, never a fender or a steering wheel handed over on the way to a finished car.² The first slice of your project should be the skateboard: small, rough, and something a person could genuinely use today, not a fragment of the finished version with the wheels missing.

3. List what it must do, then cut that list in half

Write down everything you think the smallest useful version needs to do. Do not filter yet, just get the honest list out of your head and onto a page. A first list like this usually runs eight to fifteen items, because it is far easier to imagine a feature than it is to imagine actually shipping it.

• Show what is available right now
• Let someone claim a slot
• Confirm the claim back to them
• Let the owner see who claimed what
• Handle someone canceling
• Send a reminder beforehand
• Track repeat use over time
• Take payment up front

Now cut it in half. Not the easy half, the half that is genuinely not required for the smallest version to be useful. Keep only what breaks the sentence from step 1 if it is missing. In the list above, confirmations, reminders, payment, and history are all real features, and all of them can wait. "A person cannot claim a slot at all" is the one that cannot.

This is not corner-cutting for its own sake. It is close to how the Agile Manifesto's own principles put it: "Simplicity, the art of maximizing the amount of work not done, is essential."³ Every item you leave off the first list is work you do not have to build, test, explain, or maintain yet. That is not a cost. It is the entire point of scoping down.

4. Pick the one task you can finish today

You now have a short list. Do not start at the top and work down; pick exactly one task from it, the one you can actually finish today, not this week. "Today" is doing real work in that sentence: a task that takes three days is really three or four tasks wearing one trenchcoat, and you have not actually broken it down yet.

• Small enough to finish in one sitting, a few hours at most
• Produces something you can look at, click, or run when it is done
• Does not depend on a task you have not started yet

If nothing on your list fits inside a day, that is useful information: step 3 stopped one level too high. Break the top item down again until one piece of it fits inside today. A task you can finish gives you a real result to react to. A task that spans a week gives you five more days to quietly change your mind about what you are building, without ever noticing you did.

5. Choose tools only as the first task needs them

Resist picking a framework, a database, or a whole stack before you know what today's task actually requires. Tool selection done up front, before you have shipped anything, is usually procrastination wearing a research hat: it feels productive, and it produces nothing a real person could ever touch.

Let the task in front of you name its own tools. A task that is "sketch the one page a visitor sees" needs paper or a whiteboard, not a framework decision. A task that is "get that page loading in a browser" needs an editor, and once you actually reach that point, a working development environment set up for exactly what this task needs, not everything you might eventually need six tasks from now.

6. Take the first step, and define how you will know it worked

Do the task. Then, before you move to the next one, decide in writing what "it worked" means, ideally before you even start, not after you are already looking at the result and want it to have worked.

Judge it the way the Agile Manifesto's principles judge progress on anything bigger: "Working software is the primary measure of progress."³ Not a plan, not a diagram, not how good the idea sounds out loud. A real person could use the smallest version and it did what the sentence from step 1 said, or it did not, yet.

Worked example: a gym owner tired of texting for sign-ups

Here is the same six steps run against one small, real complaint, from a vague idea to a first shippable slice.

None of that first slice needed a login system, a database, or a payment processor, because none of it was required for the sentence in step 1 to be true. Those can all show up later, once a real person has actually claimed a real spot and the idea has earned its next slice.

1. 1Write the idea as one sentence naming what it does and who it is for.
2. 2Name the smallest version of that sentence a real person could use today.
3. 3List everything the smallest version needs to do, then cut the list in half.
4. 4Pick the one task from that list you can finish today, not this week.
5. 5Choose tools only once the task in front of you actually needs them.
6. 6Take the first step, then check it against a definition of "worked" you wrote down first.