Blast your way to success with the Product Spaceship

The Product Spaceship is a fun, visual metaphor used to explore, surmise and define a product and its key components to help teams better understand what it is that they’re creating, in a fast and effective way. I first discovered the Product Spaceship during a facilitation training course with Daniel Stillman. A fellow participant, Bartosz Rakowski, shared a version of this activity that I latched onto and subsequently evolved over the last year, and I’d like to share it with you today.

When to use it

• To collate information derived from other workshop activities
• To quickly scope out the vision for a product as part of discovery
• For on-boarding new team members and helping others understand the project

If you’re developing an MVP then you might consider having multiple spaceships. For example your MK1 Spaceship might be the initial release and your MK2 Spaceship a feature-complete product. Like real spaceships most of the product will remain the same throughout the delivery cycle, so treat the constituent parts as modular.

What you’ll need

• The people that are working on and overseeing the project
• A whiteboard and pens
• Post-its and Sharpies
• A4 paper (optional)

Ideally your spaceship will be created somewhere where it can live-on throughout the project and be seen by those involved. If this isn’t possible then make sure to capture it via an alternative method.

Remote teams might want to consider using a platform like Mural to run the workshop.

The activity

• 1) Design your spaceship (optional)
• 2) Target
• 3) Payload
• 4) Crew
• 5) Entertainment deck
• 6) Engines
• 7) Passengers
• 8) Mission control
• 9) Risk Nebula
• 10) Next steps

1) Design your spaceship (optional)

Duration: 10 minutes

This makes for a great warm-up or icebreaker exercise. This isn’t only a fun way to get to get to know one another but also a way to start giving your product a personality. Small teams might want to nominate someone to draw while the others direct — larger teams can work on components individually or in small groups.

For the spaceship itself you’ll need:

• A cargo bay for our payload
• Quarters for our crew
• Quarters for our passengers
• A feature-packed entertainment deck
• A power-plant to propel us

To help round-out the product you’ll also need:

• A target destination
• An HQ for mission control
• A nebula to store our risks

If you’d rather skip this step just draw out a rocket with clearly defined sections ready to populate with post-its. The data we collect is more important than the metaphor used to collect it!

2) Target

Duration: 5 minutes

What are the ambitions of this project and how will they be measured? What does success look like? Measurable targets are the most actionable, so consider things like KPI’s, OKR’s, NPS’s and CSAT’s.

Examples:

• 1000 new registrations by Q3
• 100 referrals by Q4
• Have the most satisfied customers in our industry

3) Payload

Duration: 5 minutes

What is it that we’re delivering? How do you want a user to describe your project to a friend or colleague? Think of this as your elevator pitch.

Examples:

• A community that empowers you to create positive change
• A revolutionary dashboard that will help us make decisions and reward our staff
• A 2-minute multi-platform booking experience

4) Crew

Duration: 5 minutes

Who are the people on the ground that are taking us on this journey? Project Managers, Engineers, Designers — define the team and their roles and expectations from the project.

Examples:

• Sally Messier (Product Design Lead) — Responsible for design output and usability testing, estimates design tasks
• Harold Magellanic (Front-End Developer) — Responsible for delivering the application mark-up and documenting implementation. Estimates development tasks
• Kate Andromeda (Junior Designer) — Supports Sally Messier, responsible for brand guardianship

5) Entertainment deck

Duration: 5 minutes

What are the specific features the product will have? Focus on USP’s and core functionality and extend outward where appropriate or necessary.

Examples:

• Weekly video conferencing sessions with local counsellors
• Track staff emotional state and correlate it with workload
• The fastest booking platform in the industry

6) Engine room

Duration: 5 minutes

What is motivating us to create this product and make it a success? Who’s problem are we solving, and what is the cost of failure?

Examples:

• National Lottery funding has unlocked this opportunity
• Stress in the workplace for online support agents
• The need to innovate in our industry and separate ourselves from the competition

7) Passengers

Duration: 5 minutes

Who are the people that will be using our product? User personas, case studies, or even user stories can go here.

Examples:

• Jane Juno (Counsellor) — Time-poor. Likely to be using a mobile device. Extensive user of technology
• “I tend to be the most stressed at the start of a call, I’m anxious about how angry they will be” — Zane Ali
• As a prospective customer I want to book a hotel visit on my commute because I want to surprise my partner tonight

8) Mission control

Duration: 5 minutes

Who are the project stakeholders? These should be the people that own the product and that are responsible for its success. What are their roles and expectations?

Examples:

• Beckie Moon (Product Owner) — Decision maker, responsible for delivering the project.
• Kamal Phobos (Technical Director) — Consulting on technical delivery
• Anne Callisto (Marketing Director) — Signs off on look and feel, brand owner

9) Risk Nebula

Duration: 15 minutes

What risks might block the path to our goal? Are there any assumptions that we need to validate?

Examples:

• Counsellor availability
• The customers willingness to invest in staff well-being
• The ability for the hotel to accurately communicate how many vacancies are available

So you’ve got a product spaceship, what next?

Your spaceship is a way to communicate your project. What it is, who it’s for and why it exists. It works best if you can display it somewhere that’s obvious, but at the very least clearly signpost it in your documentation and ensure that any new comers to the project are taken through it in detail.