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
- This is the book that I saturated out with
- This is also amazing, and is a must read for anyone who is involed in software of any kind
- Everything you ever need to know about scrum in one very short blog post
- There are some great resources on https://www.mindtheproduct.com, here are some of my favourite talks on the topic:
- Watch this, this is the best one
- This one explains that iterations sometimes are not enough
- This one is okish, but good for general background on lean methodologies
- If you are interested in why UX matters this is a good call to action
- This is a great post that Francis Rowland sent me last week.
# 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