Context
The iBiz Women in Tech programme at Strathmore University supports early-stage women founders building startups across Kenya. I was invited as a practitioner-facilitator to run a 2-hour session on Prototyping & Minimum Viable Product — taking founders from first principles to a hands-on exercise in a single sitting.
The brief was specific: these were non-technical founders who had a business idea and early customers but had never built a formal prototype or thought rigorously about what their MVP should — and shouldn't — include. The session had to be instantly practical, not theoretical.
The challenge
Most startup education at the MVP stage suffers from the same problem: it either stays too abstract ("validate your assumptions") or too tool-focused ("here's how to use Figma"). What founders actually need is a framework for deciding what to build first and why — grounded in examples close to their own context.
- Founders were at wildly different stages — some had paper sketches, others had already spent months building features users didn't want
- Non-technical founders often conflate "prototype" with "finished product" — the educational gap was significant
- The pressure to impress investors meant founders were adding features to their decks rather than removing them from their products
- Most Western MVP case studies (Airbnb, Facebook, Amazon) felt remote — the session needed to connect those examples to East African startup reality
"The most common mistake I see early founders make is building a product nobody uses because they never showed it to a real person before writing a single line of code."
— Opening frame, iBiz MVP Workshop · Strathmore UniversityWorkshop agenda
The 2hr 15min session was structured in four modules, each building on the last — moving from concept to case study to hands-on application.
Prototyping Fundamentals
What prototyping is, why it matters, and the two types founders need to know.
- Paper prototypes — fast, cheap, disposable
- Digital prototypes — Figma, Sketch, Adobe XD
- 4 steps in prototyping: objectives → wireframing → build & test → iterate
MVP Development
What an MVP is, how it differs from a prototype, and how to identify core features.
- MVP definition — the most basic version that delivers value
- Identifying core features vs nice-to-haves
- MVP vs prototype — functional product vs visual representation
- Collecting feedback, measuring success, iterating
Practical Application
Overview of prototyping tools and real-world MVP case studies from companies founders recognise.
- Tool tour: Figma, Sketch, Adobe XD
- Case studies: Uber, Facebook, Amazon, Airbnb, WhatsApp
- Discussion: what their MVPs had in common
Best Practices, Group Exercise & Q&A
Prototyping and MVP best practices, followed by a hands-on group exercise and open Q&A.
- Define clear objectives before you prototype
- Keep it simple — one core feature first
- Gather feedback actively, not passively
- Group exercise: paper prototype homepage for a fitness app
Module 1 — Prototyping fundamentals
The session opened with a clear, jargon-free definition: a prototype is an experimental artefact — from paper to digital — that design teams build to test ideas on real users before committing to full development. Not a spec. Not a finished product. A learning tool.
The two types of prototypes were introduced with examples founders could immediately recognise:
The 4-step prototyping process was introduced as a loop, not a linear sequence — reinforcing that iteration is the point, not the exception:
- Identify objectives and goals — what do you want to learn or test from this prototype?
- Sketch and wireframe — rough sketches to outline ideas before committing to digital
- Build and test — construct the prototype and gather feedback from real users
- Iterate — refine and improve based on what you heard, then go back to step 1
Module 2 — MVP development
The MVP module tackled the most common misconception head-on: that building more features is the same as building more value. An MVP is the most basic version of a product that delivers value to early adopters — not a half-finished version of an ambitious product.
Three questions structured how founders thought about their own MVPs:
- What is the single core problem your product solves? — strip everything else away first
- What is the absolute minimum set of features needed to solve that problem? — not the features that make it nice, the features that make it work
- How will you know if it's working? — define success metrics before you build, not after
Module 3 — Real-world MVP case studies
The case study section was the most energising part of the session. Rather than abstract examples, I walked founders through four companies they used every day — showing what those products actually looked like at MVP stage and how far they were from the products founders know today.
Two founders struggling to pay San Francisco rent saw conference attendees unable to find accommodation. Their MVP: photos of their own living room air mattress on a rough website. The question they tested: will strangers pay to sleep in someone else's home?
Zuckerberg didn't start with a global social network. He started with a digital "face book" — a web directory with photos and names of Harvard students. One campus, one feature: look up your classmates.
Bezos wanted the world's biggest bookstore. His MVP: a simple website listing books. When an order came in, he personally bought the book from a supplier and shipped it by hand. Zero warehouse, zero inventory system.
One feature: instant messaging over the internet. No voice calls, no video, no status updates. It solved a single clear problem — expensive international texting — and did only that until it had critical mass.
An iPhone app for San Francisco only that let you tap a button and a black car would appear. No shared rides, no Uber Eats, no driver ratings. One city, one product, one button.
What's the single thing your product does that someone would pay for or use right now? That's your MVP. Everything else is a future version.
Best practices shared in the session
Define clear objectives first
Before you sketch anything, write down what you want to learn from the prototype. A prototype without a learning objective is just art.
Keep it simple
Test one thing at a time. Avoid unnecessary complexity and features that don't align with your objective. Simplicity helps users engage with the prototype rather than get distracted by it.
Gather feedback actively
Watch users interact with the prototype. Listen more than you explain. The moment you start defending a feature to a user is the moment you've stopped learning.
Start with a single, well-defined core feature
WhatsApp launched with instant messaging only. That decision — to do one thing exceptionally well — created the traction that funded everything that came after.
Launch to a small group first
Airbnb collected feedback on their platform's usability before they had 100 users. The small group is your most valuable signal. Don't skip them to get to the big launch.
Measure before you add features
Define what success looks like before you build. Conversion rate, user retention, task completion — pick two or three and track them. Features without metrics are guesses.
Group exercise
Design a paper prototype homepage for a fitness tracking app
Founders were split into groups of 3–4 and given blank A4 paper and pens. The brief was deliberately constrained: prototype the homepage of a fitness tracking app. Think MVP — what are the essential features only?
The exercise surfaced exactly the tensions the session had set up. Every group's first instinct was to add features. The facilitator's job was to keep asking: "Is that a core feature, or is that a nice-to-have?"
- Groups had to justify each element they drew: "why is this on the homepage?"
- After 20 minutes, groups presented to each other and received one piece of feedback: "what would you remove?"
- The final 10 minutes were spent on revision — most groups removed 30–40% of what they had drawn
Every single group's first prototype included a leaderboard, social sharing, and nutrition tracking. None of those are the core job of a fitness tracker. The exercise made the bias toward features visible.
When asked "what is the one thing a user needs to accomplish on this screen?", groups converged on: logging a workout. Everything else was secondary. That clarity typically arrived 25 minutes in, not at the start.
Outcomes
Qualitative feedback collected at the end of the session indicated that founders left with a clearer, more ruthless view of what their own MVPs should contain. Several participants reported in follow-up conversations that the session had directly influenced how they presented their products to investors — stripping back features to lead with the core value proposition.
The session has been reused and adapted for subsequent iBiz cohorts and for separate UX Design courses at Strathmore University, where I have been an instructor since 2018.
What I learned about teaching design thinking to founders
- Case studies do more work than frameworks. Abstract MVP theory doesn't land. The moment you show a founder that Bezos was personally hand-shipping books, the concept clicks. Context-rich stories beat slide frameworks every time.
- The best workshop moments happen in the exercise, not the lecture. Founders need to feel the tension between "everything I want to build" and "the one thing a user needs" in their own hands. Paper prototyping achieves this in 20 minutes in a way that no talk can.
- The facilitator's job is to help founders hear their own assumptions. The most effective interventions were questions, not corrections: "Who is that feature for?" "What would happen if you removed it?" "How would you know if it's working?"
- Non-technical founders need permission to start ugly. Many founders delay prototyping because they think it has to look finished. The explicit permission to draw a box on a piece of paper and call it a feature is genuinely liberating — and it's something design practitioners forget to give.