At Cogent, we get a pretty healthy learning budget each year to spend on personal and career development. The budget includes both a financial element (up to $3,000) and time (up to 5 days) to spend how we want, in order to grow and reach our individual development goals.
Even though I’m a Lead Engineer, I decided to focus my budget this year on understanding Product Management better, so that I can be a better Product Engineer. I really believe that high functioning product teams are ones where each team member understands what the others are doing, and a big part of creating a successful product is the Product Manager.
These are some of my takeaways from the Leading the Product Conference 2019.
Leading the Product
The conference was opened by Radhika Dutt with a talk titled “Iterate less, build more”. This talk set the tone of the conference in some ways – there was a theme of being critical of (the misuse of) lean, agile and data-driven development. Her main points were around the importance of a clear company goal.
She introduced a framework called Radical Vision, which includes an extended vision statement generator. She called the longer form of the values statement the ‘company values source code’ – you use it to compile your public vision.
My take away: The company goal should be represented in different ways to different people.
Next up was Sherif Mansour from Atlassian talking about “The data-driven paradox”. Using real case studies, he outlined how data without context is really dangerous. The most extreme example was a junior developer who on a hack day decided to remove the lowest usage feature in Jira: The “remove an account” button.
Just because a feature has low usage does not imply it has low value. As an example, “airbags are low use features in cars – let’s remove them!”
Sherif said that you need to take into account context when making decisions about usage. The example he used to back this up was the Trello ‘to do’ feature – it is only used by 4% of users; however, it’s used by 40% of people who are trying to get things done.
My take away: Be data-informed, not data-driven. Value questions over data.
Kent Weathers then spoke about “How to launch a product”. He compared Juciero’s launch to the Telsa Model 3 launch. Juciero was a $650 WiFi-enabled juicer, with one-time use juice pouches that got sent to customers on a subscription. The trouble was, they never actually asked the market if squeezing fresh juice was a problem that needed solving. They also never put the thing in front of a customer. That didn’t stop them from burning $118 million developing must be the single most over-engineered machine press ever. They finally shut down after someone worked out you could take the juice pouches and just squeeze the juice out by hand.
Contrast that to the Telsa Model 3, which did $14 billion (yes: BILLION) dollars on launch week, making it the most successful product launch of all time – for comparison, the Apple iPhone 6s only did $9 billion. Not bad for a product that didn’t actually exist yet (There was an 18-24 month wait for delivery). He attributes that to the fact that the Model 3 is the third generation of the product, it is priced attractively, and the launch was perfectly aligned with the rest of the product lifecycle – marketing knew what they were selling, they knew the market and price point they needed to hit.
Weathers suggested that if Juicero had a proper launch plan, with launch day goals and metrics they would have noticed far earlier that the numbers weren’t adding up. Conversely, Telsa knew their launch was going to be successful.
My take away: You need to think about your launch before development starts, while you build and even AFTER launch.
Sally Foot from Photobox dived into why “your customers hate your AI and what to do about it”. Photobox invented a machine learning algorithm that could design beautiful photo albums by automatically selecting aesthetically pleasing photographs, removing the pictures where your cousin’s eyes are closed, and correcting for light and colour.
It turned out though, that people making photobooks don’t want robots picking photos for them – it’s a very personal thing.
Not to be deterred, they reimplemented the UX so the AI made helpful suggestions at the right time, but stayed out of the way when it could potentially get in the way.
My take away: You shouldn’t have a separate data science team, you should have data scientists in your delivery team in the same way developers and designers are.
The final talk was from John Zeratsky, a designer at Google Ventures and one of the inventors of the Design Sprint. He took us through a case study of a cute little delivery robot designed to ferry toothbrushes and towels to hotel patrons.
The product was nearly ready to be shipped to an early adopter customer, but there was a question about how punters would interact with it. You know how awkward it is to be in an elevator with another person – imagine how weird it would be to have a robot in there with you too. Did the robot need a personality? If it did, would people freak out?
To test, they ran a Design Sprint and came up with three things to test out – giving the robot a face, offering a game that people could play, and making the robot dance upon a successful delivery. To avoid adding code for the tests, they faked the face and the game using an iPad and had one of the engineers make the robot dance by controlling it manually using a Playstation controller (which they could already do in debug mode).
On the fifth day, they rented a hotel room, put an ad on Craigslist and got five people to test out the changes. They each called reception to ask for a toothbrush and were delighted and surprised to see a little robot turn up. They learnt that the face made the users smile, the game was useless and the robot dance was a revelation.
My take away: You can test big ideas with little effort in 5 days with a bit of creativity and the Design Sprint framework.
Overall, I was surprised about how much of the stuff they were talking about wasn’t new to me (I’m not a product manager remember). That said, Product Managers seem to have a knack for distilling ideas into consumable and actionable process – giving these processes names makes them much easier to remember and as a result, use.
I’m constantly amazed at the range of skills that product managers exhibit – as the discipline grows and evolves it may be difficult for the industry to pinpoint exactly what a Product Manager is, but there is no doubt WHAT product managers do is crucial to delivering a great product to your customers.
To find out more about our learning budget and other Cogent benefits, head to our careers page.