Bioinformatics

Product Development: How to seriously screw it up if you really want to


I feel fortunate to work with people I can learn from. One of them is Ian Mulvany, Chair of the BioJavaScript (BioJS) Production Committee (he is also head of Technology at eLife). He sent the post below in an email and found it too useful to let it get buried in my inbox, so I post it here with his permission. He tells us a bit about his experiences on how to make a great product and what works and what doesn’t. Read on!

# a little about product development

OK, so, about product development.

Basically, it’s a bit woolly, and there are lots of different ways to come to it. Ultimately though, its about two main things:

  • Figuring out what the best thing is to do
  • Doing that thing

There’s lots of scope for many different disciplines to help – UX, UI, Marketing. BA, Dev, Analytics, throwing chakra sticks in the air and hoping that you gain some insight.

In my personal experience things that suck are:

  • Wasting effort doing stuff, and then changing your mind later and throwing away all of that effort
  • -Doing a lot of effort, and in the end building something that no one uses

The first of these suck a lot more than the second one, at least with the second one you have a chance to learn something, and maybe get it better the next time.

# can we define what product development is?

Well, ummm, maybe, ummm, maybe not. Anywhere people want to get things done, there is room for someone to look at the process with product development glasses on. You often hear this as relating to taking the voice of the user. I would say that that’s related to my two key points above.

# are there things that can really help?

Yes there are!! Horayy. Some of these are:

  • Know what’s happening (roadmaps, vision statements, project tools like Jira are all aids to this)
  • Finding out what’s working (analytics, marketing, user testing, more user testing, amount of money you are making, are all aids to this)
  • Feeding back the stuff you have learnt into the next iteration (having an open development culture that is willing to learn is helpful here)

# resources

Here are some of my favourite resources

# my personal lessons

Each of the following I learnt the hard way. This is not a complete list of how to screw up, I still have a lot more learning to do, but I stand by all of these.

  • Focus on shipping product
  • Make the work visible
  • Keep your developers happy
  • Keep track of user pain
  • The human is harder than the technical (e.g. mendeley institutional edition)
  • Test with users
  • Don’t use InnoDB for heavy read write apps
  • Don’t over normalise your database, think about application views rather than pure data modelling
  • A product is not enough, it needs a supporting business model
  • A business model is not enough, it has to scale
  • Don’t develop in a waterfall methodology
  • Don’t leave your biggest opportunity on the table
  • Control as much of your infrastructure as you can get away with
  • Don’t be afraid to work outside your comfort zone – e.g. the design of the site
  • Even with API’s – think of users over the technology stack
  • When you find really talented people, figure out how to get out of their way

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s