Building the Wrong Thing Faster Two Delivery Successes That Led to Product Failure

Two Delivery Successes That Led to Product Failure Product X - Building the wrong thing Product Y - Building the right thing at the wrong time Disclaimers Stories from my POV A lot I didn’t know Not dogging on product managers

Product X

Product X – The Product An “onramp” to the flagship product Goal: Increase market share for flagship product A solution geared towards SMB Goal: Capture market share in area flagship product struggled Cloud-based, IT management solution Goal: Enter new, yet tangential, market Confused? So were we. Couldn’t explain what the product did to my mother – that has uniformly proven to be a problem.

Product X – The Delivery Team Money was flowing Skilled and effective Excited to build a SaaS product Strong DevOps culture Awesome QA team Analytics baked in Date-driven “We will make our dates.” Confident with respect to process (Scrum)

Product X – What went wrong? Engineering and PM leadership not aligned Constant tug of war Variations in answers to basic questions were staggering Progress > Product Deliver or die; released with holes that were never filled PM’s control over “the line” limited Continuous delivery without continuous learning Little learning from customers (or the market)

Product X - As the end was nearing… Shifted product strategy Built to monetize Left a trail of undone/unused capabilities Attempted to improve “usability” Grew the team to build more faster

Product X – In the end… Product was EOL’ed Greater SMB, business line sold off 50’ish people were let go

Product Y

Product Y – The Product Video on Demand system Demo’ed well Streamed movies to set-top boxes via cable provider networks Goal: Drive sales of the company’s proprietary hardware and operating system Demo’ed well Netflix concept of ala carte TV and movies circa 2000 Tech worked

Product Y – The Delivery Team Skilled and effective engineers Cool kids in a not so cool company “The best team in the building.” Everybody a tester Mostly scope-driven “We do what we say we are going to do when we say we will do it.” 6 to 9-month cycles; big pushes at the end Confident with respect to process (traditional)

Product Y – What went wrong? No real sales, marketing, or product management Market conditions weren’t right Pirating rampant during this time Targeting the wrong buyer Cable companies versus consumers Hardware & tech were expensive

Product Y - As the end was nearing… Practically gave it away Added support for a new platform Hoped to target hotels and apartment buildings Found different work for team members

Product Y – In the end… Product was EOL’ed Team remained intact Nobody was let go (but a few quit)

Product Over Progress

We can see… Process success doesn’t guarantee product success Product matters Map a product journey Share the vision Measure, Validate, Learn, Adjust Product management is hard We weren’t willing to learn? … to be wrong?

How do we get it right? The product Early discovery Windchill Mobile App Early discovery Market/User research Learning outside the code Validated narrowing and product choices

Windchill Mobile App Delivery rocked! Process was tuned (Scrum) Skilled team; Incredible collaboration Delivery was constant Trust extended to team Everyone knew where we were going Process was tuned (Scrum) Unburdened by existing codebase QA solid

Windchill Mobile App – Why did it work? Product management led & was responsible Continuous delivery -> continuous validation -> continuous learning Built “just enough” to test Usability testing Customer roadshow – demos & roadmap reviews Made adjustments Product was king (then delivery…then process) Showed progress to execs with product demos not metrics

Windchill Mobile App – In the end… Users were excited about the product Delivered “on time” Beta for sales-enablement Fast-follower, public release with remaining capabilities Happy executives Team felt pride in product (not just finishing)

Keys to Success Let product people lead/own Put product first (then progress…then process) Embrace learning Measure, Validate, Learn, Adjust Build less of the wrong thing

Anne Steiner linkedin.com/in/annesteiner @annesteiner7 anne.steiner@devjam.com