Forget research, let’s build something! – Redux


I’m somewhat surprised that I didn’t receive even one comment — for or against — on my post entitled Forget research, let’s build something!.

As Product Managers, we regularly talk about understanding the market, the market problems, user requirements, needs etc. And then creating solutions that best address those needs. But, as I said in my post:

in the software world, …given the very low barrier to entry, a “good idea” can be quickly iterated on and developed and become a successful endeavour without a lot of research, and market segmentation, and problem identification, and persona development etc.

What do you think? When is research needed, and when can you just “go for it”?

Saeed

Advertisements

9 responses to “Forget research, let’s build something! – Redux

  1. In the software, especially software as a service, world, research is needed more than ever. Though the research is needed for different reasons than it is needed in traditional product development.

    The challenge for managers of SaaS products is that it’s so inexpensive to build a “good idea” into the product. In my experience building and growing products, “good ideas” are very common. They come from everybody in the organization, investors, customers, journalists and academics. These “good ideas” are generally truly good ideas: they could turn into viable businesses on their own, or add valuable functionality to your product.

    The challenge, however, is that with every feature you add to your product, with every new audience you try to address, you add to the confusion around your product, and you dilute your message.

    “Good ideas” turn out not to be so good when there are so many of them cluttered around the interface that you can’t find the one that solves the problem you have at the moment. “Good ideas” that don’t solve problems are useless when you are trying to communicate the value of your product.

    Only by defining a segment and building a product that solves the biggest pain points for that segment can you build a focused product with a communicable message. This is the type of product that people will pay for, love, and recommend to others.

    To build this type of product takes a detailed understanding the market. This means doing the legwork of traditional market research.

  2. I’d say research is defintely needed when you’re entering uncharted territory.

  3. Other times when the product satisfies an important user need, you could just go for it.

  4. Why not go for it and do your market research as you go? Certainly you do need to figure out what is your market but why would you want to spend 3-4 months pondering about the viability of a software product when you can spend that same amount of time building and gathering, not second guessing, feedback from the market itself?

  5. I would say for a startup in a new market, it makes sense to go build the product then putting resources initially to research, the market/users will show the ways to use the product / service and then using that feedback to apply segmentation and show value will be critical.

    Also, in most cases an idea would have emerged by experiencing the problem, say Intuit’s founder seeing the problem he faced, so in a way the initial research is done, although not in the traditional sense.

  6. If time for research and time to market are comparable, then the question we need to research-on is “whether the feature is detrimental to the product/company?” the damage could be anything like damage to the brand(set completely wrong field expectations), to over all schedule of the roadmap.

    We need not put research effort on every detail that goes into the product. The amount of research must always be driven by the Investment and/or the consequences of the investments are high.

  7. Go for it when the risk of failure is low. Not every feature and detail of a software product needs go through a rigorous needs assessment. Sometimes it just makes more business sense to get a quick prototype, share it with potential users and see what sticks. BUT it should be developed within the context of an overarching theme, not just because it’s cool. And if the reaction from the acid test is negative, find out why.

  8. You should ask that question for every release 🙂

    I’d say there are a lot of variables…

    Is there an existing customer base?
    Are there any existing expectations?
    How much pre-existing related knowledge are you bringing to the table?

    I tend to ‘just go for it’ often enough 🙂 but I’ve been in the same company, dealing with the same customers & issues for years. I know what our customers are looking for and am comfortable moving quickly to give it to them… usually that pays off. That being said, there should still be a reality check that needs to be done at some point…

    But for big, or new projects (esp. new for you), always put in the research up front, make sure you know what you are getting into, the particular nuances of your potential market and customer base etc. This isn’t saying to get bogged down in research, but due diligence pays off in the end…

  9. @Everyone

    Thanks for the comments. I guess asking a second time for feedback worked. 🙂 I’ll write a post soon continuing this topic and incorporating some of your comments.

    Saeed