How do I write a tech product vision?

If you don’t know where you’re going, you’re not going to get there. You need a vision. So, how can you write a quick, simple, effecting tech product vision?

In this FPQ we’re going to build up a quick vision for a local medical clinic, a doctor’s surgery. It will be a simple iOS app.

Let’s cut straight to the components.

Who is the product for?

Start with a core user group. Don’t make it so specific you narrow it down to a handful of people. Don’t make it so generic you make it everyone, ever. For our app, we will be experimenting with a minimum viable product (MVP) to test it out, so we are looking for early adopters. Let’s then start with a user group called busy commuters. The reason this is useful is that it may help us imagine the constraints they have. More likely to be mobile, so wireless will be important. The service may not work underground. Users can’t use the app when driving, etc.ed

What will it be called?

Don’t over think it. We just need a working title. Let’s call it the Clinic App.

What problem will it solve?

We then need to be clear on what problem this will solve for both the business and the users. For the sake of balance, let’s think of three for each. We think of these as outcomes.

How will we know we’re having an impact?

For this we need to assign a measure to the outcome. Let’s give some examples:

• Reduction in no-shows: 20% reduction compared to pre-app figures.
• More choice: Specific doctors & nurses are chosen by the busy commuter, instead of being assigned one randomly.
• More convenience:  50 extra appointments booked a month, as it’s easier to see availability.

Note: the numbers are just an indicator. They’re a control number we set at the start simply to see what impact features we build have. Numbers can go up and down. That’s fine – it’s just information we use to make an informed decision. 

Here’s what the final product vision statement looks like.

FOR Busy Commuters

THE Clinic App

IS A WAY to get a new customer cohort base interacting with the surgery

Problems solved for the clinic	Problems solved for the user
Reduction in no-shows (-5%) Better staff scheduling (1hr admin time per day) Better communication (200 newsletter sign ups.)	More convenience (50 extra bookings a week) More choice (Specific staff chosen for consultation >10% of the time) More privacy (descriptions of ailments sent via app in advance >50 times a week)

 

This will allow the team to start placing product bets into a story map, create a minimum viable product and get started experimenting with the new app.

This approach is simple, clear and measurable. It is easy to communicate and whilst not a huge feasibility study and cost-risk benefit analysis, it allows value to be developed quickly and gives simple measure to spot quickly whether a return on investment will be achievable or not.

Should the product be a success, more user cohorts can be added as can more outcomes.

Want to keep reading?

• Check out other Frequent Product Questions just like this
• Want a better team? Take a look at our Frequent Agile Questions
• Sign up for free training with our FAQs LIVE
• Download our useful factsheets on all things agile