|
|
Viewing entries tagged with 'product discovery'
MVP vs. Product Vision
Earlier I expanded on the notion of Minimum Viable Product (MVP) and I promised a series of articles that explores aspects of MVP that often cause product teams confusion. In this article, I’d like to discuss the relationship between the MVP and the Product Vision.
Lean Thinking
A while ago I posted an article on people that I think have something really valuable to say to product leaders. One of those people I discussed was Eric Ries, author of the blog http://www.startuplessonslearned.com. I also promised that I’d share a glossary to map the nomenclature and concepts he uses with the terminology I use in my writing and my work with product teams.
Minimum Viable Product
One of the most important concepts in all of software is the notion of minimum viable product (often referred to as “MVP”). But if you’ve been around software products for a while, you know that term is used in many different ways, and while the term intuitively resonates with people, there’s often a lot of confusion about what this really means in practice.
The Two Core Competencies
Good product teams must be good at product discovery, which means they must get good at learning quickly. They need to be able to zero in on the appropriate target customer, identify the key problems to solve for those customers, and typically the most difficult part of all, apply technology and user experience design to come up with good solutions that will solve those problems.
The Importance Of Failing
Recently a friend of mine sent me a link to this short video from totally outside of the technology field. The video is called “Why You Need to Fail” and it’s by Derek Sivers. Even though the examples are from very different domains, I thought that this short video very eloquently made one of the most important points in creating great products, and I strongly encourage all of you to watch it (especially the second half).
Product Discovery With Live-Data Prototypes
In my last article I discussed the keys to product optimization including A/B testing. However, I emphasized that this type of A/B testing is not the same as the A/B testing we do during product discovery. In this article I’d like to talk more about how we utilize live-data prototypes and A/B testing to facilitate product discovery.
Technology First vs. Needs First
There’s a debate that’s been going on in the design and user research community because the legendary Don Norman wrote an essay in which he did an about-face and decided that doing user research to start a project was mostly a waste of time.
Product Discovery for Non-Technology Products
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.
The Product Discovery Plan
In my last article, I discussed the situation where Product Discovery is essentially not discovery at all, but rather just a mad dash of just-in-time spec writing so that the engineers can be kept busy. I discussed how important it is that the date not be driving everything at the expense of the value of what will be created.
Product Discovery vs. Product Optimization
As readers of these articles know, I am a big fan of high-fidelity prototyping and user testing on current or prospective customers. These techniques form the basis of Product Discovery; it’s the key to discovering the minimum viable product – a product solution that is valuable, usable and feasible (see www.svpg.com/product-discovery/).
