There are many things to do when starting a company. Find desk space, register the company, get a bank account, set up the website, and all the other tasks that require different hats to be worn. If the idiom were reality, hatters and milliners would be present at every startup accelerator.
You quickly need a product or service to offer your customers. Without this, you won’t be in business for long, unless you already have other revenue streams or your investors or lenders are patient. Funnily enough, they never seem to be.
You’ve probably already thought of an idea already; you think it’s going to change the world for the better, solve someone’s problem, or mitigate someone’s risk – possibly you hope it’ll do all three. So how are you going to get from A to B, where A is nothing but a headful of ideas, and B is a product in someone’s hand being used “in production”?
We faced the same challenge when we started a company six years ago, armed only with a couple of laptops and a list of good contacts. You’ll need to work hard on networking throughout your journey – it’s hard to bring a product to life without a lot of help from others.
Laying the groundwork
We wanted to disrupt existing practices in an area of healthcare research that aims to understand patient outcomes and experiences, outside of clinical trials, in almost any disease area. First, we needed to establish at least an outline “product-market fit”. We knew we had to ask ourselves – and answer – some very searching questions. These include:
- Who are your customers?
- What problem(s) are you trying to solve for them?
- Do your customers even know what problem(s) they have?
- Will customers pay (and continue to pay) for that solution?
- What are they currently doing instead?
- If something already exists, how does it compare?
- How will you measure success?
- What does good look like?
- Are there any early KPIs/OKRs you can use to judge your progress?
We set out to validate our ideas by working with senior clinicians at The Royal Marsden Hospital in London, one of the world’s leading hospitals dedicated to cancer treatment and research. They helped us understand the contours of patient experience in oncology, many aspects of which extend across other disease areas too. We also ideated at length with industry experts at major pharmaceutical companies to gain insight into the types of evidential gaps they are trying to fill and where our solution could help with that.
Finally, we checked the regulatory landscape to understand external constraints such as ethics, pharmacovigilance, data protection, and security requirements. Make sure you know who your key opinion leaders are and then ask as many questions as you can – most people are happy to have a chat over coffee, especially if you aim to improve the way things work in their industry.
The building phase
With your assumptions challenged and your offer refined, you can move on to a highly creative and productive phase that will shape your product much further and quicker than you have so far. You need to start product iteration, which is a cycle of designing, testing, prototyping, and perfecting. Regular inspections and feedback are key to this process; as is listening. Remember the Lean methodology of “think big, act small, fail fast, learn quickly”.
For this, we created the cheapest, quickest version of the product that we could and got feedback on it as early as possible. This way the cost of “failure” was very low, and we could easily pivot or simply remove functionality and try something new. You can find several ways to create minimally viable versions – wireframing tools help a lot here, but I’ve seen early product ideation done on paper.
In our early user testing, we implemented clickable wireframes for mobile devices, which we chose as our initial target form factor. One version was a fully featured prototype that had the feel of a complete app but was built at a fraction of the cost. There are also now no-code or low-code solutions that go a stage further and provide basic functionality that further blurs the lines between prototype and minimum viable product (MVP).
Asking for feedback
Who should you ask for feedback? It could be anyone: friends, family, and colleagues will all have useful thoughts. All feedback is a gift, and this is one that keeps giving. The best option is to ask your prospective end users.
Don’t get too stuck on exactly who to ask. I guarantee the minute the rubber hits the road, you’ll start learning things you didn’t realize, or think were important yet. When we got feedback from people living with an autoimmune condition that caused muscle weakness, particularly in their eyelids, we soon realized it was hard for them to scan up and down a long screen of text or icons – we hadn’t expected that, but now it became obvious.
We then organized phone calls, online surveys, and even in-person focus groups at venues in London, Paris, and Milan. There are many options where people can take part remotely, even remotely screen and voice-recording to get stream-of-consciousness feedback from users, but in-person testing is still important as the level of insight it provides is great.
Choosing your priorities
When you have some feedback, organize it into areas of functionality; let’s call them “epics”, given we’re already considering an agile approach. At this point, you’ll be creating a backlog of product ideas. You can’t really expect your users to tell you which of them will provide the most value; it’s up to you to listen carefully. Find out what they’re doing now: can you imagine them switching from that to using your shiny, new application instead?
As part of our discovery, we wanted to know if people track things about their disease already, such as medication, side effects, and treatments. If so, where do they already do that? We found quite a few people using spreadsheets to do this. If you give them your app, is there any friction in moving over to it – how likely is it to happen?
You’re often not competing with the things you think you are, such as better features and functionality. Often you’re competing for people’s attention, the span of which is now frighteningly short. Dealing with patients suffering from acute or chronic diseases, we found users already have a lot going on in their lives and spend time managing their condition, treatments, and side effects – we usually couldn’t expect them to spend long using our app too. There are exceptions, such as a group we studied who needed regular blood transfusions which take the best part of a day in the hospital during which they had time to provide feedback. A different consideration here is hospitals are often places with restricted connectivity, which can limit the use of mobile devices.
Finalizing your product roadmap
Finally, it’s time to review the backlog and the epics you identified. Try to arrange these into a product roadmap. There is much to cover in product management but this would be a good time to familiarise yourself with two key frameworks.
First is the Kano Model, which helps us prioritize features on a product roadmap according to the degree to which they will satisfy users. I like this framework because it focuses on user delight while creating the biggest bang for your buck. It also explains why today’s “wow” feature soon becomes expected.
The other model is the Design Council’s Double Diamond. This encourages you to take a two-stage approach in your thinking; initially divergent exploration, and then convergent focus. It does this across two areas called the problem space and the solution space.
We’ve used this to great effect as a means of moderating conversations while planning our product roadmap. The idea is to prevent you or your stakeholders from jumping straight to the first solution they can think of. Taking the time to check if you really understand the nature of the problem and brainstorming for several competing solutions sounds like common sense but be prepared to explain the Double Diamond repeatedly on your journey to a successful product.
As you can see, the process of designing, testing, prototyping, and perfecting is endless but you’ll recognize when you have something good enough.
Our first oncology study app was quite basic, but we soon added more functionality. It’s also about removing features. Users had asked us for a feature that found people nearby with a similar stage of disease for support, but it wasn’t used as much as we had hoped. In the end, we withdrew it. Nothing in product management is an exact science and the data and feedback can only tell you so much. Don’t be precious about any of your ideas or assumptions as they will probably all be challenged at some point and your product will usually end up looking quite different when your journey from A arrives at B.
