Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Creating Breakthrough Solutions: What Customers Really Want?

DZone's Guide to

Creating Breakthrough Solutions: What Customers Really Want?

Developing imperfect products and releasing often for customer feedback is the best way to lock in your product-to-market fit.

· Agile Zone ·
Free Resource

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

I believe one of the most important aspects for the success of any product is the product-market fit. I’ve seen many great products fail miserably in achieving commercial success because they don’t solve some of the important customer pain-points. Paul Graham aptly said, “The most common mistake companies make is to solve problems no one has.” And, of course, there could be several other reasons for such failures, despite it being a great product, but that’s not what I‘d like to focus on here. While I don’t have a silver bullet and neither do I claim that these have always worked for me, here are some excellent practices I’ve seen product teams following and they might just work for you.

Customer-Driven Innovation

For one of the new products we’d launched in the enterprise security space, our team followed this unique approach of signing up potential end-users, understanding their complete job in terms of their day-to-day activities, mapping each of them in the product capabilities and then coming up with the overall functionality for the product. This was a great learning experience. We often tend to focus on one great feature and get overly excited about it. Understanding what the users need to perform their job, and not just one great feature, was a big revelation into the overall value we were bringing to the table.

Joint Development Partners

It’s one thing to have "domain experts" advising you on your product strategy and completely another thing to have real users and their decision makers sweating it out with you in trying to achieve a common goal of creating value. Nothing beats the beta users who are highly motivated in installing the product in their environment and giving you the much-needed critical feedback. You should feel lucky if you have some, especially if it’s an enterprise product.

Despite all the ways mentioned here, especially for enterprise software products, we end up getting brand new requirements for that one big deal, for which we need to respond quickly. This is where the last point matters.

Release Early, Release Often

A lot has been said on this topic. But how often do we effectively implement it? We all want to get our product out in the field doing wonders for our customers as early as possible and get back to us to communicate improvement areas. But then the strong urge to release that perfect product dotting all the I’s and crossing all the T’s keeps us from releasing that so-called imperfect version. Very few teams can overcome the dilemma and have the courage to leap and very often, I have seen them win.

Agile Development, Continuous Testing and Smart Automation

Despite all the precautions and planning, there are always bigger, unexpected opportunities that keep knocking at the door. If the engineering is not willing or ill-equipped to respond quickly, the opportunities are lost in no time. Change is the only constant and being agile is the only way to survive. Your response time is always an indicator of how mature and innovative your development processes are. Do focus on them. They will come in handy someday!


This article originally appeared on QualitiaSoft's blog. 

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Topics:
agile ,continuous improvement ,continuous delivery ,cd ,ci ,automation ,continuous release ,end user feedback ,product market fit

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}