post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Creating metrics that matter

A case study: Launching a product process in a project-based company

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

How much are product managers getting paid in 2024?

Leading product ops at Delivery Hero with Koen Dubelaar

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

“You’re not as competent as you think” 5 lessons from Ken Chin on navigating a product career (CPO, Spark Networks)

Everything wrong with the product management job market. And how to fix it

Simon is a data scientist, with a background in product management, and has worked for a range of data technology companies on both sides of the fence including vendors like Hortonworks and Red Gate Software and numerous heavy data users in retail, hedge funds, and web. He focuses on big data analytics, machine learning, and how these can be used to make better products.

Senior Product Manager

Simon Elliston Ball

<p><img loading="lazy" decoding="async" class="alignnone wp-image-16533" src="https://www.mindtheproduct.com/wp-content/uploads/2019/06/vasa-300x225.jpg" alt="" width="851" height="638" srcset="https://www.mindtheproduct.com/wp-content/uploads/2019/06/vasa-300x225.jpg 300w, https://www.mindtheproduct.com/wp-content/uploads/2019/06/vasa-768x576.jpg 768w, https://www.mindtheproduct.com/wp-content/uploads/2019/06/vasa.jpg 1024w" sizes="(max-width: 851px) 100vw, 851px" /></p>
<p>One of the advantages of having customers to visit everywhere is that you get to see a lot of places. Recently I was lucky enough to get stuck in Stockholm after a meeting, and got the chance to visit the excellent Vasa museum. So what? What does the well preserved wreck of a 16th century Swedish warship &#8211; the world’s most high-tech warship when it set sail &#8211; have to teach us about organisation and modern business? Well, for one thing, it sank.</p>
<p>The launch of the Vasa did not go well. About 1.5km into its maiden voyage, it capsized, flooded, and sank to the bottom of the Stockholm harbour, not to be seen again for another 333 years. An inquiry was of course launched into what went wrong, and more importantly, who was to blame. Of course such things are common on any failure to launch a product as well. So what did go wrong?</p>
<h2>The Engineering Process</h2>
<p>Let’s look at the engineering process. Shipbuilding in 1628 was not unlike the way many agile software development teams operate. There are no drawings or plans for the Vasa, because that’s not really how it was done. An expert shipbuilder just sort of worked out which bits needed to be built (I mean, they’d built a few of these before, and they all pretty much worked). This one was a bit different (it had a second gun deck) but that was fine, they built it on the same basic framework and adapted to requirements as they became clear. Meanwhile the customer (King Gustavus Augustus) and the product owner (the Vice Admiral) tweaked and added requirements long after the basic hull was laid out. The ship builders willingly complied with the requests from their customer, the king.</p>
<p>Shortly before the official launch party, one nervous engineer decided it might be worth doing a few integration and acceptance tests on the ship. He tried valiantly to demonstrate the flaws to the product owners in the hope that shipping a disaster could be avoided. He had 30 sailors (let’s call them QA engineers) run back and forth across the code (sorry, deck) until the boat nearly capsized in its dock. Experts declared the fundamental design and architecture to be bad because there wasn’t enough ballast to ensure stability. Cognisant of urgent customer demands, the Admiral decided to ship it anyway, because no one wanted an angry King on their hands. And so, the product launched, and promptly sank.</p>
<p>Part of the lesson here might be seen as the need to test earlier and test often, as advocated in agile coding practices. However, this has to go further. Testing in a lab can show up a lot of flaws, but you can’t really tell what will happen to your product until you send it out into the open water and sail it through a few squalls in the sales and marketing channels.</p>
<h2>Blame Flows Faster Than Water When Things go Wrong</h2>
<p>Ultimately the inquiry decided that no one was to blame, because, well it was the King’s fault, and a little bit the VP who overrode the team’s test-based decisions on ground of corporate expediency. There’s a lesson in accountability here. Who gets the blame when a product is fundamentally flawed at launch? In software, where the lives of sailors are not on the line, it’s maybe easier to shrug off blame and carry on pretending you’ve learned something for next time, but someone usually gets fired. It’s rarely the person at the top of the accountability chart.</p>
<h2>Avoiding a Vanity Project</h2>
<p>The Vasa is a classic example of a CEO vanity project. The ship was festooned with emblems of power. Its stern was so tall and elaborately decorated with symbols showing how amazing and powerful the leaders were, that its vanity contributed significantly to its instability. How often do products fail because heavy internal political concerns outweigh the features that would perform in the market (like basic buoyancy)?</p>
<p>What can we learn from this failure, and all our own failures? Stakeholder management. Make sure you create an environment where you can save power from itself by speaking truth, and if you can’t persuade your leadership with good tests and real data, make sure you build in a lifeboat.</p>
<p>Hopefully we can avoid some of the past mistakes, because it’s unlikely that a dedicated bunch of conservators will be dredging up your product in 300 years’ time and pumping the holes full of wood preservative. So it might be worth taking a few precautions and launching something that makes it out of the harbour.</p>

Sink or Swim: What can we Learn from the Vasa?

Simon Elliston Ball

Read more

Comments