Tag Archives: lean

When I built products the stupid way

In 2007, ProductRepair (name changed), a market leader in its industry, was facing some serious threats:

A rapidly maturing business.

New “digitally native” entrants with greatly enhanced data collection abilities.

A 100% call center based customer service model, with an escalating cost per interaction.

Service partners with increasingly divergent strategies.

Legacy IT infrastructure that made it difficult to compete.

To tackle this, the company’s product management team proposed an innovative and bold “interactive customer web portal” (remember: this was 2007), thus transforming the company’s traditional “brick & mortar” type business model into a “21st century digital model”.

The vision was pretty cool actually. The strategy was to provide:

  • “An integrated closed-loop customer experience.”
  • “Comprehensive product setup and support.”
  • “Enhanced full-service customer support.”
  • “Interactive multi-channel communication.”
  • “Cross-sell and up-sell platform.”

(Yes, those were the actual words used in the presentation to the CXOs.)

The benefits were the usual stuff: increased value-add, improved customer satisfaction and retention, call reduction, after-sale revenue opportunities, “big data” insights, etc.

The new digital business was to have five core capabilities:

  1. A product “locker” for the the user to keep track of their purchases
  2. Self-troubleshooting
  3. Live chat and email support (again: 2007, so pretty new stuff back then)
  4. Request service on their malfunctioning product, with real-time claim adjudication, and service status and resolution
  5. Up-sell/cross-sell platform

As an ambitious young product manager, I was put in charge of building and launching this bold new digital capability.

Our (my) approach was classic:

A month spent writing a PRD and an RFP to source a development partner.

$10,000 spent on “consumer research”.

$320k in 6 months spent to get to “First Release”.

Another $10,000 spent to produce a flashy “demo” that we could showcase at the Consumer Electronics Show.

Over $1 million spent in a year to add features, fix bugs, and re-design the system.

Result?

E.P.I.C. Fail.

Delivery was late. Customers hated it. Sales was unhappy. Execs were angry.

It wasn’t just that we took a waterfall development approach vs. agile…

It’s that we made a terrible business decision: we decided to deliver our entire product vision in our first release.

This “build it all” approach added a tremendous amount of needless risk to our delivery and strategy.

If you’re reading this shaking your head, laughing at me, I know, I know…

In the new world of agile/lean, we’re all much savvier to the benefits of an incremental and iterative approach to product development.


Credit: Jeff Patton

Needless to say, I learned my lesson (the hard way, I might add)…

And yet, turns out, product managers still struggle with this.

See, it’s not a choice between waterfall vs. agile. It’s not a project management problem.

It’s not even a software development methodology problem.

It’s a business innovation problem.

That’s why when I recently saw this question posted by Ganesh on a PM community, my past flashed before my eyes, and I knew I had to help him out.

Here’s his question:

I need some advice around building a service incrementally around user needs.

We’re building an online service that has the following needs (in priority): Cereal, Beef, Vegetable, Fruit. (Shardul’s note: Names of actual needs not listed here to protect any confidentiality concerns.)

As Cereal is the number 1 need, my idea was to design and build this need out and test it with users while further researching what users wanted around Beef. Once we have more information around Beef, we can then incorporate that into the Cereal prototype, thus building it out like building blocks. And repeating this cycle till all needs are met and the service is built out incrementally.

The opposite is that we research ALL the needs in one sprint, and find out what people want. Then build the whole page, which has all the needs together. I can see how this would be positive in terms of seeing the entire picture, and keeping the content in context of each other. But my concern here is that we miss out the details.

Any advice would be appreciated.

Maybe you’ve been faced with a similar dilemma…?

Here’s the answer I gave to Ganesh, verbatim (though, with the food groups):

In case you can’t read the text in the image…

Ganesh, since I don’t know the complexity of your service (I don’t want to assume just because you’ve listed four functions that “seem” straightforward that there isn’t complexity), allow me to share an approach we took on a previous job I did as a thought provoker.

My inclination is always to get product to customers as fast as possible without compromising on quality and ensuring every release attempts to deliver real user (and business) value.

With that philosophy in mind…

I’d consider asking a Designer to sketch out the “whole picture”, like a clickable mockup or prototype (no “plumbing” behind it) and see if I can get some qualitative user feedback on it. I’d take this option if I believed that this could be accomplished relatively quickly.

Once done, I’d actually consider going ahead and building and delivering the Cereal functionality first because you stated it’s the #1 need, and I can get users to actually use the thing and start getting real feedback on it allowing me to focus on usability improvements (because they will be needed.)

I can then prioritize these needs along with the remaining functions on my roadmap/backlog for delivery. For example, my next release could strictly be usability improvements for Cereal, or these + an increment of the Beef need (assuming there’s value in delivering it in increments), or Cereal usability improvements + Beef in its entirety. (I’m assuming here Beef is second most important after Cereal.)

By having my designer sketch the “whole picture” upfront and sought user feedback on it, I’ve hopefully reduced the risk of wholesale design changes downstream. (Though, it’s still possible.) Even if there are changes that need to be made to the Cereal feature as you get user feedback and look to add the other features, a competent designer should be able to manage the process (since they’ve already done the “whole picture”) in concert with you, and determine the best approach to releasing them to the user.

This allows me to accomplish all three of my needs: design for the whole picture, get product to users as quickly as possible, and start acting on user feedback.

I would opt not to have the designer sketch the “whole picture” if it was going to take a long time (like a month).

The crux of my answer is a strong proclivity for getting product to customers as fast as possible without compromising on quality, and ensuring every release attempts to deliver real user (and business) value.

It’s a philosophy that has guided every product I’ve worked on since that debacle back in 2007. #ProdMgmtHardLessons