Advice for Developers – Product Doctor Diagnoses (OTA 2010)

This year at Over the Air 2010 (OTA) I set up a Drop In Product Surgery for mobile developers, which focused on how to make their products more commercially successful.  OTA is a two day grass-roots mobile developers event which is in its third year and offers an interesting schedule of keynote speakers (Sir Tim Berners-Lee headlined this year), sessions, panels, workshops and competitions for the all-night hack-a-thon.  This is a really unique event with a great atmosphere; it also presents an opportunity to try out new ideas and work on them alongside some amazingly clever people.

OTA Hacking in the Great Hall, London Imperial.

Here are some of the most common prescriptions that I wrote at the surgeries.

1. Talk to your end users, early and often

  • It is NEVER too early to talk to end users – you don’t need to wait for a prototype – start with the concept
  • You can check that your assumptions about their current behaviour are correct
  • You can try to discover pressure points that need solutions
  • If you have a great piece of functionality, get end users together to help you “productise” it – if the user session is properly facilitated you can get them to build the range of potential propositions for you
  • Even if you have already imagined or built a product, you still shouldn’t be afraid to do the above; let users to strip it back to its functionality and see what propositions they come up with
  • Users can also help you prioritise your feature list – this helps get the user angle in to your roadmap
  • There is nothing stopping you engaging with your end users now – just go and mingle – if you think people will use your product at the bus stop, then go and talk to people at bus stops!

In every user group that I have run over the years, I have always been surprised by the reactions and suggestions that come up.  It is crucial that users are involved in the process from concept through to launch and beyond, to ensure continuous improvement of the product.  Think of how many innovations fail – and the cost that gets sunk in to development.  Try to understand your end users as well as you can; get them to help you to define the key benefits and how are you going to communicate your message.  This theme re-occurs again and again throughout this post!

2. Size your market & know your competition

  • Size your market opportunity – this will help to inform your initial commercial viability and validate assumptions on your revenue forecasts
  • Think about the different end user segments for your product – who is going to use your product? (again, this is where end user input can be crucial)
  • Do your competitor analysis; write up your SWOT analysis and that of your competitors. It will help you to focus on what you are – and are not – and to find your competitive advantage.
  • Ask yourself what you have that is special. Unique can be perceived in many different ways – it may be that your user experience is unique although the functionality is not.  Perhaps you have a special route to market that will help you to reach your end users
  • If you can’t believe why your idea has not been done before, research it fully – you may learn why it has never been brought to market

3. Define your product

  • Avoid feature over-load.   Can you define your features and corresponding benefits in 3 bullet points? Find the real jewels in your offering and focus on them. You can save yourself time and money
  • Be aware of taking on the giants. For example, if your product is offering photo uploads as part of the offering, from a user perspective you may actually be competing with Flickr!
  • Getting people to change their behaviour is very difficult. Think through what you are asking people to do and whether there is already an established way of doing it
  • Think carefully about creating a new community – how can you plug in to online communities that already exist? Building and managing a community is a significant piece of work with ongoing overheads. If your product is dependant on that community remember that it can take years to build up
  • People now want to have conversations. There are growing numbers of people that want to engage with products, be that just by reading or making comments or sharing their opinions with their friends on social networks. Where this is appropriate for your product, do consider building in these features. This is a core part of the product design and it will delegate some of the marketing effort to your users

4. Recycle!

  • Think about what technology you already have built – before you shelve it, talk to users and think about the scenarios where it could be “productised”

5. Consider your routes to market

  • Are you going direct? Are you going to have the resources to build and execute a marketing plan yourselves – and set up the customer support function?
  • How will you drive people to find your App in the App store?  Research ways of  “DIY PR” (Lisa Devaney & Lauren McGregor) to get the best value!
  • Do you have some functionality that could be really useful to an existing brand? Again, this is another great example where end users can help you to identify how their existing brand experiences could be improved by what you have to offer
  • User insights can really help to strengthen a pitch. “We have run insights workshops with these different segments, and here are prototypes that have come out of that”
  • Which brands are in a highly competitive market and have some money to spend? Many brands want to be “in mobile” but they don’t quite know how to weave this channel in to their offering

Closing Comments

It was an absolute pleasure to have the opportunity to work with some really talented developers.  I hope that I helped them think through some of the more commercial and user-focused elements.

I was also proto-typing the “Product Doctor is in” event format.  The name “Product Doctor” and the offer of “Product Surgeries” worked well as a short-hand descriptor and there was a clear understanding of what the appointments were for.  At 25 minutes long, the appointments were convenient and accessible for event attendees.  Although the OTA event environment is informal, these sessions felt quite formal – as it is with any doctor.  This level of formality meant that the conversations were very focused and in 25 minutes, we could diagnose and identify some treatment.  The feedback from my patients was that I had them looking through a totally different lens.  I hope they will take their medicine!

Finally, thanks to Katrina Damianou for helping to develop the concept; Flora Gordon for spreading the word; my patients for being great guinea pigs and above all, the OTA Team – Helen Keegan and Daniel Appelquist in particular for letting me experiment!

5 thoughts on “Advice for Developers – Product Doctor Diagnoses (OTA 2010)

Leave a Reply

Your email address will not be published. Required fields are marked *