This post is part of the Tech Tuesday series brought to you by NTEC.
It starts with a great product idea. But many inventors don’t realize there is a gap between the product you bring to market versus the one that achieves customer satisfaction. There are two important groups that can increase your chance of being right when it comes to product features, workflow, and visual design.
Time to market is a key concept for product delivery. Reduced time to market preempts competition, shows responsiveness to customer requests, and generates revenue sooner. It is the basis for commitments to investors, your sales team, customers, and the market. Without ignoring time to market, it’s always a good idea to plan, design, and deliver products with another concept in mind: Time to customer satisfaction.
Bringing a product to market and having satisfied customers are not the same thing. Time to market is straightforward, it’s when you release it to sales and customers.
Time to customer satisfaction is difficult to measure. It is a subjective combination of a customer’s willingness to buy and use the product.
Product development planners expect version “X” to go to market with little or no additional work. The customer support team handles defects, and a roadmap of enhancements is developed for a future release. All is good.
But sometimes, there are unforeseen design problems discovered by customers. Sometimes there are design flaws that would render the product unusable even if it was “defect free.”
Regardless of the reason for rejection, repair fundamental flaws immediately. Doing so requires depth that only your core product development team has.
The challenge is that your development team is executing plans and commitments for version “X+1” which are already committed to sales and customers.
You have a few options:
- Replan and change commitments.
- Overwork your team to repair version “X” and maintain delivery of version “X+1” simultaneously.
- Cut corners on version “X+1” as much as possible without impacting revenue and customer
- satisfaction.
The right option depends on your business. For example, a small start-up needing cash is going to go for the latter two choices. Whether the choices are sound business decisions is not my point. What matters is that they feed on themselves to increase the likelihood of a future delay in version “X+1” time to customer satisfaction.
Adjusting your future plans and commitments is a serious consideration. The consequences range from lost credibility to severe financial harm (lost contracts, stock price, etc.). The goal as a product development leader is to reduce the risk of a gap in time to customer satisfaction. Let’s explore two ways to engage customers to decrease time to their satisfaction with your product.
Choosing the correct set of features for your product is hard. Build too few or build the wrong features, and your product may not sell. Build more than your customers need, and you are later to market. Determining an appropriate feature set requires customer interaction and an understanding of their goals.
There is no process that guarantees a perfect (or even good enough) feature set each time. End user engagement improves your odds. In my years of building enterprise systems, I’ve been fortunate to experience several methods that yielded excellent results.
As you build your product, identify the problems they are having that are significant enough to make them pay for a solution.
The Advisory Board
Here is where an advisory board comes in. Advisory boards focus on major product strategy, features, and workflows. They assist you to determine priorities of major features, workflows across features, and your standing relative to competitors (within ethical and legal constraints).
It may be counter-intuitive, but businesses don’t buy features, they buy solutions to problems.
As you identify business problems with your advisory board, have them explain why solving the problem matters to them. Let’s take an example of a feature allowing a physician to order a complex lab test electronically.
The distinguishing value of this feature is the extent to which it makes it easier for a physician to enter orders. In turn, physician satisfaction increases, making them more likely to refer patients to the customer’s hospital. To a hospital, physician referrals can make or break them.
When constructing an advisory board, gather 8-12 people with industry breadth and understanding of operations within their organizations. Invite people representing various dimensions of your product.
For example, a product for physicians would have an advisory board comprised of multiple specialties, geographies, and hospitals.
User Groups & Customers
I encourage you to have non-customers represented, as well. They often provide new ways of thinking about problems, since they don’t “know” your product or its workflows.
Most important, you want this group to tell you where your strategic mistakes are – before the market does. But as we all know, the devil is in the details. As a rule, an advisory board will not get involved with day to day product development activities.
I recommend a second group of customers to help shape specific feature designs and workflows. I’ll refer to these people as user groups. Members of user groups are involved in the daily operational workflows for which the product is intended to be used.
Beginning with the first storyboards, user groups take part in product demonstrations. They are aware of features delivered and the features under consideration for the next iteration. Once demonstrated, they immediately confirm or correct workflow and visual designs.
Members of a user group are people who use your product or are involved in the work processes your product makes more efficient.
Their feedback ranges from poor page navigation to label names. I’ve been in user groups where we spent 30 minutes debating the appropriate name of a button. If you think that is too much time, consider the time you will spend refuting a review that your product is unintuitive.
Depending on your intended audience, something as simple as a label can send a signal that you don’t understand your market. After all, if you don’t use the correct label on a button, why would your customers trust you to understand the market itself? An effective user group can help you avoid this embarrassment.
A user group is also a sounding board for questions or ideas that come up during the product development process. A good indicator that it’s time to engage the user group is when the team starts arguing about feature navigation and workflow. Unless you have clear feedback from users, it is best to bring the various arguments to the user group. In some cases, you may find out the team was arguing about the wrong thing, or about something of little concern to your users. It is much better to learn this during development instead of after you ship.
The use of these two groups may increase time to market. But you will avoid potential problems by utilizing an advisory board and user group, far outweighing the time constraints posed by using them.
I’ve found that these two groups dramatically increase your chance of being right when it comes to product features, workflow, and visual design. They help you make the all-important decision of what to build and what to leave out.
Equally important, the advisors and users involved throughout take a high degree of ownership. They become product advocates, since it becomes “their” product design.
I encourage you to identify potential members of advisory boards and user groups. Your customers willingness to participate might surprise you. After all, helping you is the best way to help themselves.
