svpg
FREE newsletter

Subscribe via RSS

Subscribe

Tag Cloud

product discovery management product management company culture product portfolio planning product development process product strategy great products product owner innovation marketing user experience design scrum product marketing agile engineering prototype testing project management high-fidelity prototypes product development

Browse by Date

  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • April 2006
  • March 2006
  • February 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005
  • April 2005
  • March 2005
  • February 2005
  • January 2005
  • HOME
  • Services
    • Product Management
    • Product Marketing
    • Technology
    • User Experience
    • Public Workshops
  • Articles
    • Index
    • Blog
  • Clients
  • Resources
  • Company
    • Team
    • Manifesto
    • Contact Us

Product Discovery for Non-Technology Products

Posted by marty cagan on March 5, 2010

Tags: product discovery

Article: Product Discovery for Non-Technology Products

I’m often asked whether or not the concepts that I advocate and write about are applicable to non-software products as well as the consumer and business internet services that I almost exclusively focus on.  My answer has always been that I really didn’t know because in my career I have only built software technology products.

However, there is one exception.  When I began the process of writing a book, I wanted to apply as many of the concepts I advocate as possible, not just to see how well they worked, but also because I felt I genuinely needed them to help me come up with something of value.

The book has been out now for over a year, and there are more than 40 reviews on Amazon, nearly all 5 star, and sales have continued to grow steadily far beyond what I had a right to hope for.   So now I finally have some confidence that the techniques truly can help with non-technology products as well.  In this note I thought I would highlight the learnings from this project.

Many management consultants write books as a form of brochure for their services, but I wanted this to be something for the people that could never afford to work with me directly, or in corners of the globe I am unlikely to visit, and also to have something that persists.  So to me it was important that the book provide real value.  Here are the main product discovery techniques that I used to come up with the book:

First, I needed to discover which concepts were unique to the companies and teams I had happened to work for, and which concepts applied more universally.  Fortunately my profession provides me access to a large number of leading technology teams, so I was able to visit a range of customers to learn in depth about the challenges they face.  So effectively I was doing user research and product discovery from the very start.

Second, I identified a set of six product leaders that were what I considered representative of precisely the target audience I wanted to reach, and I asked them if they’d be willing to serve as my “charter customers” (I didn’t actually call it that – I asked them if they would be willing to help me with this book by answer ongoing questions, and provide detailed review of the drafts).  But the point is that I really did try hard to get the book to the point where at least this handful of people found true value.

Third, I used my blog to post articles about specific topics, and then I used the feedback, mostly site analytics, comments and follow-up questions, to gauge which topics were most relevant and helpful, and to address the questions pro-actively by improving the content.

Fourth, I created a high-fidelity prototype of the full book by weaving the individual topics together into the whole, and also looking at the form factor including title, cover design, and interior design.  Using digital printing technology I created a prototype of what I hoped to be the final product.  Just like with software, I was amazed at how much I discovered once the book was in this realistic form factor.  Even something as basic as the page size (the aspect ratio in particular) looked great online, but clearly looked wrong once we did the prototype.

Fifth, I sent this prototype to an expanded set of reviewers as well as to several hundred attendees of a conference that I considered representative of the target market.  This was my form of beta release, and many problems which had gone undetected until then were caught and corrected.  One consequence of the feedback was the decision to produce the book in hardback rather than soft cover.

At this point, I believed I had real evidence that the book would serve its purpose and provide real value.  The prototype also enabled me to get accurate manufacturing costs.  Only then was the book sent to production.

Hopefully the above doesn’t sound easy – the full process took nearly three years (although the first two years were really figuring out which topics I wanted to write about).  There were several people that helped with important elements of the book.  I had a good editor, a terrific designer for cover and interior design, and a great company that had strong experience with printing and production.  Anyone that would like introductions to any of them just drop me a note.

But I do think the principles of product discovery, having deep and ongoing access to target users/readers through the charter customers, and the use of prototypes and product optimization techniques, all were essential to the success of the book. 

It is interesting to contrast the process I used with the conventional publishing process, which I would argue is essentially waterfall.   Authors and publishers of course create drafts and get feedback, but usually by other writers or editors and not by the target readers.   Publishers sometimes create multiple versions of covers, but this is to get the feedback of their sales and marketing people.  Publishers also occasionally produce an “advanced reader copy” prior to the main production runs, but that is for getting reviews before publication rather than broad beta testing.

But my purpose here is not to try to advocate for changes to the publishing process and industry.  That is already happening.  The Internet has made it dramatically easier to build a community, get near real-time feedback of your ideas, and to publish directly and inexpensively – especially digitally.  Rather, I wanted to explore the applicability of the techniques our technology industry depends on to non-technology products.

If you are working on a non-technology product and have tried applying any of these techniques, please drop me a note and let me know your experiences.

A special thanks to my long-time friend Mark Coggins, a senior technology executive as well as the author of a successful series of crime fiction novels (all based in the Bay Area and with a tech industry backdrop).  You should check out his work at http://www.markcoggins.com.


  • Product Management
  • Product Marketing
  • Technology
  • User Experience

© 2009 Silicon Valley Product Group. All rights reserved.