RentSpree: a polished concept that answered a later question

Ask the room: what can a polished prototype establish, and what can't it?

Both RentSpree links need my access.

By the end, you'll be able to

1. Identify the exact decision in a brief: the target user, the constraint and the success event
2. Separate firsthand observations, interview evidence, documented facts and assumptions
3. Work backward from a completed customer job to a small, testable flow
4. Use AI to speed up research synthesis, screens and iteration, while you own the product decisions
5. Run a task-based prototype review, and use the findings to revise the PRD

Five questions to keep asking

Session plan

Wireframe, prototype, PoC, MVP: what's the difference?

A step before the four build steps, and a learning loop after

The base deck teaches four build steps: a good PRD, user goals and steps, key screens, and stitching them together. My interview work adds a decision before them and a learning loop after them.

Write the brief in one sentence, then mark the evidence

For [this user], we need to learn whether [this proposed change] helps them complete [this outcome], under [these constraints].

If the brief asks for activation, an elegant expansion concept belongs later. That was the RentSpree lesson.

The useful output is a decision document

Define the moment the user's job is done

Each screen advances the job or exposes a decision

A teaching cut of the Brightwheel flow. Screen count is a forcing function for focus, not a rule that every product needs exactly five screens.

A reviewer should know what it demonstrates, and what it simulates

Give someone a situation, then watch

A positive comment about the look of a screen is useful design feedback. It doesn't establish repeat use, willingness to pay, feasibility or a business result.

AI makes the choices visible faster. The PM makes them.

The PM owns the brief, the customer outcome, assumptions, scope, trade-offs and how feedback is read. The director conversation grounded the work, but it was still one interview.

Same process, different decision

A fifth, Wayfair Home Projects, adds a delivery lesson: check the final demo link as a reviewer would.

Stay close to the charter

Focused: Creator Studio Productivity · back to the team's actual problem and intended user Contrasting branch: AI-first concept · a broader idea that pulled away from the charter

Answer the current job first

A login or an opened message isn't the completion event.

[DAVE: screenshots of Stead and Owner Momentum. Both links need your access]

Check the final demo link as a reviewer would

Three phases of vibe coding

Why front end first? Every feature costs time, energy and tokens. Moving features around on the front end is much easier, with less waiting and less heavy lifting.

It's not about building anymore. It's about validating your ideas quicker.

It's not perfect, and that's not the point. Showing the latest version is impressive, especially with senior stakeholders: general managers, CEOs, clients.

Prototype in Lovable, finish in code

The backend, GitHub, pull request and Railway slides from the base deck are follow-on material. Use them once the customer flow is clear.

Ask for the screen map before the build

Here is my brief, brain dump, and evidence. Help me create a clickable concept for one target user.

First, restate the exact customer job and the assumption this prototype should test. Separate observed facts from assumptions. Propose a flow of no more than five key screens, including one failure or exception path. For each screen, say what the user sees, decides, and does.

Use fictional data where needed and label simulated behaviour. Do not invent customer quotes, business metrics, integrations, or validation. Show me the screen map before building. Once I choose the scope, build the clickthrough and include a restart.

AI can make your choices visible faster. It shouldn't silently make them for you.

Build your own five-screen flow

A childcare centre director learns before opening that a teacher is sick and needs safe, approved coverage for the morning.

Give a partner a task. Observe before explaining.

You are the director. A teacher called out sick at 6:30 a.m. Show me how you would get the room covered.

Can a peer identify all six?

If a peer can't, revise the story before adding more screens.

What changed, and what goes back into the PRD?

1. What did the participant actually do?
2. Which assumption became more or less plausible?
3. Which screen can you remove?
4. What do you still need to learn from a real customer or engineer?
5. What sentence goes back into your PRD?

One small flow, one real person, two versions

Share it: [DAVE: where to share, e.g. Maven community / next session]

Build with us at Product Academy

• Learn, build and grow with other PMs
• More sessions like this one
• No pressure. Have a look if it's useful

Join: productacademy.io/join