Tag Archives: innovation

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.


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

The Keys To Productive Brainstorming


(c) Rob Cottingham, used via a CC BY-NC 3.0 license

Let’s face it: brainstorming has gotten a bad rap. And deservedly so.

How many of us have been part of a “brainstorming meeting” that turned out to be a total waste of time? Too many people. A purposeless agenda. Meandering conversations that go nowhere. And no follow-up afterward. Sound familiar?

In fact, doesn’t “brainstorming meeting” sound like an oxymoron?

The irony is brainstorming is actually an important tool to uncover creative solutions to thorny problems. Brainstorming broadens one’s perspective, allowing for new and unexpected ideas. It fosters collaborative thinking and the sharing of ideas, uncovers unexpected questions, and encourages creative exploration. These are important ingredients to fueling innovation.

If done well, brainstorming can be an invaluable tool for any product manager, entrepreneur or innovator.

So the problem really is that most brainstorming sessions are simply not conducted well. (OK, most are conducted really badly.)

So when Essay.Expert shared the following infographic on “Keys To Constructive Brainstorming”, with some useful tips on effective brainstorming techniques, it was a great reminder of how useful brainstorming can be if done right.

I particularly like tip #2 as it increases the likelihood of greater engagement during the brainstorming and continuity after.

Keys To Constructive Brainstorming

(c) Essay.Expert

What brainstorming practices have you seen successfully applied in your work?

Top 7 Lessons Product Managers Can Learn From Lean Startup Machine

A few weekends ago, I participated in the Lean Startup Machine workshop held in Washington DC. For some time now, I’ve been thinking about how Lean Startup principles can be utilized to drive product innovation and if they can help product management become more efficient in driving product development and delivery. The Lean Startup Machine (LSM) workshop offered an opportunity to gain hands-on learning in applying Lean Startup techniques. The workshop proved to be an unforgettable experience.

Here are the top lessons I learned from the workshop and how they’re applicable to product management.

1. “Lean Startup is about running the simplest experiment to validate a business assumption.” – @SargeSalman. As I’m learning myself, there are many misconceptions about Lean Startup. Chief among them is that lean means cheap. It does not. Lean means not being wasteful. And the way it’s applied to business problems is by challenging you to think critically about the assumptions underlying your business or product idea, and then to systematically and rigorously test them to prove them true or false.

build-measure-learnLean Startup challenges the traditional business practice of using product releases as the as the metric of execution by espousing learning as the metric of progress through the use of validation/invalidation of one’s assumptions through testable hypotheses. As a product manager, this makes sense to me as one of the things I should be doing is thinking critically and analytically about my product solution.

2. Go talk to your customers. Constantly. Lean Startup starts with Customer Development, a method Steven Blank introduces in his book The Four Steps to the Epiphany. Customer Development asks entrepreneurs to “get out the building”, which is another way of saying, “go talk to your customers.” This exactly what product management should be doing.

As such, this should come intuitively to product management, because product managers should always be focused on the customer. What the Lean Startup movement has done, though, is provided a methodical way to think about and approach how to conduct customer research. At the LSM workshop, we were forced to continually go find and talk to customers. LSM goes beyond theory by providing its participants with a tool called the Validation Board to capture one’s assumptions, create experiments, document learnings, and make the next pivot.

3. Traditional product development is wasteful. On the surface, this systematic way of hypothesizing, experimenting and learning can seem slow, because it’s not visibly tangible. Whereas a requirements document is. And code is. So both business management and even product management get trigger happy to start getting some code written, as its a way of showing demonstrable progress and makes us feel good that the product is getting developed. After all, the sooner the product is out there, the sooner we can make money!

Unfortunately, this traditional approach gives us a false sense of progress. The LSM workshop was a valuable reminder that if you don’t spend time upfront understanding your customers and their needs, you will build products no one wants. I learned this the hard way from first hand experience when I built a first-of-its-kind web product that cost a lot of money and took 6 months to launch only to achieve a miserable 2% registration rate two years after its initial launch. Ouch.

4. You must have a strong team. Now, granted, product managers can’t always choose their team members. Yet, what LSM got me to think is how many product managers think critically about the kinds of team members they’d like and then actually ask for them? And even in the case where one cannot choose their team members, as the leader of that team, how many actually spend time cultivating team unity?

5. Leadership is always, always required. This falls from the above point. The LSM workshop groups participants into teams and each team pursues an idea that received the most votes from the participants themselves. My experience reinforced the need for strong leadership by the team lead. This not only means building strong team unity of purpose, but also being able to effectively arbitrate discussions and be decisive. Exactly what a product manager is supposed to do.

6. LSM will test your influencing skills. Leadership is about influence. Product managers need to be strong influencers and negotiators. At the LSM workshop, you are working with people you’ve never met before on a team, and under a stringent timeline all of you need to come together as a team and demonstrate progress. I found my influencing skills were strenuously tested during the workshop, and it was wonderful.

7. Your solution, while interesting, is irrelevant. Sounds familiar, right? A riff on the traditional product management mantra of “your opinion, while interesting, is irrelevant”, though this takes it to the next level and targets the proposed solution itself.

Customers don't care about your product

Entrepreneurs love their ideas. They love their solutions. And so do product managers. While I’m not saying entrepreneurship and product management are the same, like entrepreneurs, product managers are natural problem solvers and we’re passionate about our solutions. Heck, I get passionate about my product ideas all the time! But the sobering truth is that it’s infinitely more important to first be crystal clear on who is your customer and what is their problem. Because the customer does not care about your product.

The LSM workshop forces you to think about the customer and their problem first. During the workshop, I saw first hand how many people struggled with staying out of the solution zone, including, I must admit, myself. By validating your customer and problem hypotheses, you’ll be in a better position to provide a real solution that solves actual customer problems.

I would definitely encourage you to attend a Lean Startup Machine workshop near you. I’ve written a recap of the one I attended on my blog and explain why I recommend product managers should attend LSM.

Have you attended an LSM workshop? What was your experience like? Have you tried applying Lean Startup principles in your work? Please share!