Holding onto your Product Mojo close
There is so much written about managing the process of developing products from a commercial point of view. But I think often the human element of product development is overlooked.
Whilst people endlessly debate runways, roadmaps and rapid releases, to my mind there is something just as important and just as potentially disastrous if it goes wrong: and that’s your Product Mojo.
What do I mean by that? Well, you’ve probably been in at the beginning of something new: a start-up business, or perhaps part of a brand-new initiative at work. It’s exciting, right? Everyone is energised. People are full of enthusiasm and new ideas flow freely. The whole team is working towards the first milestone: possibly a prototype, possibly the Minimum Viable Product. Let’s say that milestone is set for the end of next month, but when that time comes, the product’s not quite ready yet. Then what?
Well, in most instances there will be a shrug of shoulders, possibly a firm email from the finance director saying that we need to be better at delivering against what we say we’re going to do. But in reality, we’ve started the investment, just because we’ve had a bit of a hitch, we’re not going to down tools and move to the next thing.
But what is the morale of the team like now? Has it changed from day 1 when everyone on the team was telling their friends and family about this exciting new initiative they were working on? I would imagine if you asked them “how’s work?” they’d mutter something about it being a bit frantic at the moment.
It’s often impossible to predict with absolute accuracy how much your team can achieve in a specific timeframe, especially when it coms to product development. Even more so if that product relies on several 3rd party applications that it has to integrate with. So, maybe another month comes and goes and still, we’re not quite there with the first milestone.
This time the MD wants to know why we are behind. Maybe there’s a bit of a blame-game going on. Fred underestimated how complicated the Acme API was going to be; we had to move Debbie onto another project that she had been booked onto months ago. And so how are people feeling now as they miss their second deadline and head into another extension? Probably starting to resent things a little bit. Maybe they are looking enviously at their colleagues working on other projects. The buzz from the start is now being replaced with a creeping resentment. Instead of something they come in at the weekends to work on because they are so pumped up about, they now find themselves coming in at the weekend to catch up, to avoid getting more grief from their bosses.
Miss another deadline still and the people on the project now hate it. In the eyes of their peers they are either lazy or liars, or both (in reality they’re probably neither and have worked harder than anyone else in the business to get this thing dragged over the line).
And when they do finally get the product to the first milestone, we find that the bosses are annoyed that it’s taken so long and costed so much money: they probably started out telling all their friends and maybe even the press, just how smart their new product was going to be, but now they dread anyone asking them for an update. The team working on the project are sick of looking at its stupid face and just desperate for it to die so they can move onto something else. And the team that didn’t work on the project are probably either feeling annoyed that their initiatives were sidelined for the lame duck that has finally come to life, or are bathing in some kind of Schadenfreude. The truth is, even if the product does go live, unless something amazing and unexpected happens, it is dead before it even started because everyone who matters has had their faith poisoned. In short it has lost its Product Mojo.
How to keep your Product Mojo
When a product is first given life, it is going to be weak and vulnerable. Like a newborn: it needs nurture and care and love to thrive. But if the product has lost its Mojo and there is nobody with the passion to champion it, then it will die. You can apply all the Lean Start-up theory you like, but without someone to love it, it will take a miracle for something good to happen next.
But there are some things that you can do to stand the best chance of maintaining the product’s vitality.
1. Build a team In the example above I assumed there was a team, but in some instances there may only be one person assigned the job of developing the MVP. Having a team means that there is more likelihood of accountability as each person will be depending on the other to do their bit. It also means that each person’s work will be reviewed by their peer. It’s not unheard of for someone to be out of their depth, hoping that some miracle will bail them out. Always better to discover this sooner rather than later.
2. Rapid, regular releases The focus should be on small iterations and regular releases. This maintains the energy of the team and prevents people from getting taken down a rabbit hole. Even if the product isn’t progressing as fast as originally hoped, at least there is visible progress if there are regular releases. It also allows for regular feedback which reduces the risk of going off on a tangent that customers really don’t care about.
3. Working processes Product development is done by people not machines and so we have to organise ourselves in such a way that the product’s mojo isn’t impacted. Nobody can work at full tilt, 5 days a week, 52 weeks a year. You want intense bursts of creativity, not months of hard-labour. We’ve found that you normally have a core development team and then other temporary team members who will be brought on at critical times during the project. Using an Agile methodology keeps the deliverables to bite-sized achievable chunks (or “sprint backlogs”), but also intensive 1 week ‘crunches’ just before a critical milestone, where everyone drops everything just to pull everything together as brilliantly as possible, is a really great way to boost energy and excitement at a key moment.
4. Avoid functional silos Things work best when the developers are sat with the designers and the designers are sat with the marketing people. It means that everyone’s thinking about the whole process of creating and launching a product and nobody is absolving themselves of responsibility for any particular part of the process. If the development of your product is the sole responsibility of a developer, chances are they will be biased towards the functional challenges that face and away from user experience, design interface, on-boarding, pricing and marketing. But product development needs all of these things to work together.
5. Share the highs and lows As we create more of our own products, one truth emerges above all others: Results Are Everything. Positive user feedback is nice, discovering a cool way to render something on a screen is nice, getting Tweeted by someone influential is nice, getting featured by Apple is really nice, but none of that matters if your results suck. This comes down to determining your Key Performance Indicators and then tracking them. These are probably to do with money, but will also include, numbers of new customers or subscribers, number of conversions to paid, average spend etc. We’ve always tried to share these numbers with people who work here – but never as consistently and as frequently as we’d like. Recently, we built an interface that is automatically updated and sucks all our KPIs into one place for everyone to see. It sits on a big screen in the studio. How can you fail to feel part of the success and failure of a product if its vital signs are being tracked in realtime and shared with everyone you work with?
6. The learning consolation myth Too often you hear of people reinventing their failures as valuable learning. And to an extent this has some validity, but largely it’s nonsense. Yes, we learn a lot from things that we got wrong and it’s fine if you discover in the space of 2-3 weeks that an assumption or belief you had was incorrect: but that’s not a failure, that’s just research. What’s not OK, though, is to spend loads of money and loads of time finding out the same thing– if you could have discovered by, say, building a prototype and speaking to some potential customers. Because, if the product takes months and months to fail to launch, no amount of consolation about how much we’ve all learnt will ever bring back the product’s mojo.