🔧 Lab 07 — Be the Founder

Goal: experience the first two stages of the software development lifecycle — requirements and design — by planning a real app idea on paper, exactly the way product teams do.

You’ll need: paper and a pen (or any notes app), a phone camera (optional, for photographing your sketches), and about 45–60 minutes. No installation. No code.

This lab has five parts. Do them in order — each builds on the last, like the real lifecycle.

Part 1 — Pick your app idea (5 minutes)

Choose one idea from this list (or invent your own of similar size):

Neighborhood tool-sharing app — borrow a ladder or a drill from someone on your street instead of buying one.
Leftovers rescue app — restaurants post unsold food at closing time for cheap pickup.
Dog-walking buddy app — match dog owners who want company on walks.
Family chore board — a shared list where family members claim and check off household chores.
Local skill swap — trade an hour of guitar lessons for an hour of tax help.

Write your chosen idea at the top of your page in one sentence.

✅ What you should have: one sentence, e.g. “An app where neighbors lend and borrow tools from each other.”

Part 2 — Write 5 user stories (15 minutes)

Time to gather requirements. Use the template from the lesson:

As a [kind of person], I want [to do something], so that [reason].

Rules:

Write five user stories.
Use at least two different kinds of person. (For the tool app: a borrower and a lender want very different things!)
No technology words allowed — no “database”, no “button”, no “login screen”. Describe the human need only.

Here’s one to get you started (don’t count it in your five):

As a lender, I want to see who is asking to borrow my drill, so that I can decide whether I trust them with it.

⚠️ Watch out: the most common mistake is writing what the app does (“the app shows a list of tools”) instead of what a person needs (“as a borrower, I want to search for a ladder near me, so that I don’t have to walk far”). Every story starts with “As a…”.

✅ What you should have: five sentences, each following the template, covering at least two kinds of user.

Part 3 — Sketch 3 paper wireframes (15 minutes)

Now the design stage. A wireframe is a rough sketch of one screen — boxes and lines, no artistic talent required. Stick figures welcome.

Sketch these three screens for your app:

The home screen — the first thing a user sees. What’s the one main thing they can do from here? Make that big.
The “doing the main thing” screen — for the tool app, this might be the page for one tool: a photo box, the tool’s name, who owns it, a “Ask to borrow” button.
The “it worked!” screen — what the user sees after they succeed (a confirmation, what happens next).

Tips:

Draw a rectangle for each phone screen first, then fill it in.
A box with an X through it is the universal symbol for “a photo goes here”.
Label every button with the words on it.
Photograph each sketch with your phone so you have them for the final part.

✅ What you should have: three photographed sketches. If a friend looked at them, they could guess what your app does. (Try it — that’s the real test.)

Part 4 — The MVP cut-list (10 minutes)

The hardest founder skill: deciding what’s out. Remember the skateboard: version 1 must serve the whole purpose in miniature, and nothing more.

Make two columns on a fresh page:

IN version 1	OUT (and why)

Rules:

List 3–5 things that are IN. (For the tool app: list a tool, browse tools, send a borrow request.)
List at least 5 tempting things that are OUT — and for each, write one sentence of why it can wait. Examples of things founders always want too early: star ratings, chat, payments, a map view, an “invite friends” feature, dark mode.
The test for IN: if this were missing, could a first user still complete the app’s core purpose? If yes — it’s OUT.

✅ What you should have: a two-column table where the OUT column is longer than the IN column. If your IN column has more than 5 items, be braver with the scissors.

Part 5 — Write a one-page mini design doc (15 minutes)

Finally, combine everything into the kind of one-pager a real team might circulate. Copy this template and fill it in (a paragraph or a few bullets per section is plenty):

# Mini Design Doc: [Your app's name]

## The problem
Who has this problem, and what do they do about it today?
(2-3 sentences.)

## The proposal
What are we building, in plain words? (2-3 sentences.
No technology terms.)

## Users and user stories
Paste your 5 user stories from Part 2.

## Version 1 (MVP)
Paste your IN list from Part 4.

## Explicitly NOT in version 1
Paste your OUT list, with the one-line reasons.

## Screens
List your 3 wireframes from Part 3, one line describing each.

## Open questions
2-3 things you honestly don't know yet.
(Example: "How do we handle a tool coming back broken?")

That last section — Open questions — is the mark of a professional. Real design docs always admit what’s unknown. Those are the walls you haven’t opened yet.

✅ What you should have: one page that a stranger could read in three minutes and understand what you’re building, for whom, and what you deliberately left out.

🎉 Done!

You’ve done real product work: requirements (user stories), design (wireframes), and the discipline of an MVP (the cut-list). Keep the design doc — if you choose the “run a project like a product manager” capstone at the end of this course, you’ve already started it.