01 / Context
The problem and my role
Members need answers before they travel: is there space, does it fit the meeting, what will it cost, and is the reservation confirmed? Operators need the same schedule to reflect bookings, closures, and changes without maintaining separate records.
I defined the product vision, user journeys, priorities, acceptance criteria, delivery forecast, and pilot scorecard. I used Codex to support research and planning and to implement the demo from my product direction. The proposed delivery team in the PDF is a staffing assumption, not a claim that those people worked on this individual project.
Members and meeting organizers
Compare availability, capacity, equipment, and price; confirm a suitable visit and understand changes.
Coworking operator
Keep the schedule accurate, resolve booking problems, explain changes, and reduce routine assistance.
The experience at a glance
- 01Access an account and choose a visit date
- 02Compare space, suitability, time, and total price
- 03Confirm the reservation through test checkout
- 04Manage the booking or resolve a change of plan
02 / Product judgment
The choices that shaped the work
The central question
What must work reliably before asking members and an operator to trust a new booking service?
01Put dependable booking first
Prioritize account access, suitable space, reservation review, payment outcomes, My bookings, and operator controls. Handoff and waiting lists remain supporting features with Medium priority.
- Why it matters
- A useful transfer feature cannot compensate for an unclear or unreliable booking journey.
- The tradeoff
- Memberships, integrations, and multi-location support are outside the three-sprint plan.
02Make ownership and outcomes explicit
Show the chosen resource, time, total price, and outcome together. Require acceptance for a handoff, with a 15-minute teammate window followed by five-minute waiting-list turns.
- Why it matters
- Members should understand whether they have a confirmed booking, a temporary offer, or only a place in line.
- The tradeoff
- Explicit acceptance requires timely action. External notifications and live payment integration still need separate delivery work.
03Treat the plan as a forecast
Plan 15 backlog items across three two-week sprints: 26 points per sprint against a provisional 27-point limit. Review acceptance and capacity at each sprint boundary.
- Why it matters
- The plan connects priorities, dependencies, and acceptance checks rather than promising a launch date from estimates alone.
- The tradeoff
- The 78-point total and 144 planned team hours per sprint are assumptions. Points are not hours, and the proposed velocity is not measured.
03 / Evidence
From product priorities to a testable plan
The PDF is the full product case. Planned delivery and working demo behavior are distinguished throughout; the browser demo is a walkthrough, not a live coworking operation.
| Artifact | Concrete detail | What it helps decide |
|---|---|---|
| Discovery plan | Six member interviews, two operator interviews, and ten observed booking tasks; all planned. | Which booking problems justify the scope and which steps need improvement. |
| Prioritized backlog | 15 items, 78 points: 64 High-priority points and 14 Medium-priority points. | Protect essential booking work before expanding supporting features. |
| Delivery forecast | Sprint 1: access and selection. Sprint 2: booking and operator changes. Sprint 3: pilot readiness. | Advance only after the corresponding acceptance checks pass. |
| Working demo | Schedule, list and floor-plan views, test checkout, My bookings, handoff, waiting lists, and operator controls. | Walk through member and operator decisions with sample data. |
| Pilot proposal | One location and 10–20 invited members, subject to readiness and operator agreement. | Learn whether members return and the service reduces staff assistance. |
04 / Evaluation
What I would measure and why
Measures to review or validate next. These describe the evaluation approach, not achieved improvements.
| Measure | What to examine | Why it matters |
|---|---|---|
| Independent booking | Correctly completed tasks without help out of ten assigned tasks; initial target 9/10. | Check understanding of space, time, price, and confirmation. This small study would not establish a population rate. |
| Completion and repeat use | Review-to-confirmation within 24 hours; second qualifying booking within a complete 28-day follow-up. | Separate a usable first journey from an experience members choose again. Baselines remain to be established. |
| Staff effort and trust | Help minutes per confirmed booking, conflicting confirmations, unauthorized changes, and payment mismatches. | Track operational value and critical failures. The proposed 20% effort reduction is a target, not a result. |
05 / Outcome
Where the work stands
The result is a complete product case and an interactive demo that can be opened from this page. Each visitor uses a separate sample workspace saved in their browser tab. Payments are simulated, and account switching lets a reviewer try the member, recipient, and operator perspectives. No pilot results or validated business improvements are claimed.
What comes next
My takeaway
Product management means deciding what people must be able to trust first, then using evidence to decide what comes next.
Based on my submitted product case, renamed from DeskSync to SpareSeat, and the working SpareSeat demo. Research sessions, staffing, estimates, and numerical targets are explicitly presented as plans or assumptions.