Welcome! This site specializes in providing tips and tools for Business Analysts and systems development in general. If you're new here, you may want to subscribe to my RSS feed. If you'd prefer, you can also receive my posts directly to your e-mail. Thanks for visiting!

In any kind of business, whether it be it your blog, your retail establishment or your software engineering shop, you have to have a solid, attractive product to be successful. To have a solid product, you have to have an (at least) equally solid approach to defining and developing it.

Now, you can err on the side of going with a no-planning, “fly by the seat of your pants” approach to product development and just kind throw something out there and see what happens.

You can also hurt your concept by taking it to the other extreme of “analysis paralysis“; you spend so much time planning and researching that you never end up releasing a product.

So, obviously, there is a happy medium. And I won’t be defining that happy medium for you in this post. What I will provide, though, are 4 things to consider in product development that will put you well on your way to success.

This “party of four” key considerations comes from Adam Bullied at writethatdown.com. Basic? Absolutely. Product management 101 type stuff? Yes, sir. But if you’re not including these 4 key and simple concepts in your product planning you probably ought to.

Problem?

Straight-up. What is the problem the product is trying to solve? If this can’t be defined, maybe the product idea needs to be revisited before proceeding.

Vision

What is the grander scheme of the product? A vision is 100% critical because it gives you perspective moving forward. Competitive decisions, feature choices, even priorities. All these choices can be a direct reflection of the vision. Is there something that can’t be decided? Go back to the vision. Does it fit the vision?

If not, chuck it. It it does, get it in there.

Market Segments

So what”s the other really important thing before writing a stitch of code? Deciding who … the code is being written for. If that’s not known, then how can features and priorities be decided upon?

I’ve found that there is a key difference here when building consumer products to business products. The segments for a business product can be a lot more broad as opposed to consumer, which tend to need to be more specific. Why is this? I think it’s because with consumer markets you’re dealing a TON more users that need to be pleased, in most cases.

I don’t believe this is hard & fast, but just lessons learned thus far.

User Goals

So once the market segments are decided upon, the goals the segments are worked toward when using the product need to be identified, so they can actually be reached.

Related Posts