Has your company ever released new software products or capabilities that ended up not being used by your customers? Never, right? Unfortunately, I’ve seen it happen, a few times too many. Untested assumptions and guesswork can be costly and tragic.
Organizations have a finite amount of time, money, and people. Releasing new software products or capabilities that don’t get used is a waste. It is also demoralizing, especially for the team members who worked on the release.
“As you test your product concept, you will acquire significant expertise on what customers require and their priorities. You will become the go-to person.”
This post is the first of a multi-part series that will discuss product research methods and techniques to help you test your assumptions, and ensure that you are making a product or capability that your market really needs. Ideally one they can’t live without.
The research methods I will discuss in this series are applicable to any type of software company, regardless of its size, customers, or whether it makes software for business or consumer markets.
I will cover how to test your assumptions and determine whether there’s a real need for your product. These methods will also help to ensure that your product solves a real and significant problem, and ultimately delivers immediate value to your customers.
“Software innovation, like almost every other kind of innovation, requires the ability to collaborate and share ideas with other people, and to sit down and talk with customers and get their feedback and understand their needs.”
I have personally used these product research methods to test ideas for enterprise software sold to large Fortune 500 corporations. So I have first-hand experience that they work well.
I’ll be covering multiple techniques that span the entire product development lifecycle. From initial product concept, through development and QA, and post release. Generally, the more of these methods you do, the more likely it is that your product or capability will be successful.
I will also be explaining who you must involve in the process and why, including the people doing the work (i.e., development, QA, UI, UX), the people who deploy and support the product, and most importantly the people who will use it.
If you do these methods correctly, you’ll not only test the product concept with your market, but you’ll also gather the information needed to develop your minimum viable product (MVP), and create a nicely groomed product backlog. You’ll also generate market demand for the new product or capability before it’s even released.
As you lead the effort to test your product concept with your target market, you will become the go-to expert on what customers need and their priorities. The knowledge you acquire will be invaluable to the engineering team as they are building the product, to marketing and sales as you work on the product launch together, and to the field teams as they learn the technical aspects of the product.
P.S. This series will not cover how to size the market for your product (i.e., total number of addressable customers and growth rate). Perhaps I’ll cover that in a different series. This series assumes you are targeting a sizable and worthwhile market, which of course is mandatory for the success of your product.