Core vs. Features

I recently met with a startup company that intends to address end users with a productivity software product. The founders demonstrated their product highlighting many features and capabilities. I got confused. There were many good ideas in it, but all together created a highly complicated product offering. A product that an End User will not use, or at best will require user training that will increase the burden of adoption.

I learned this lesson the hard way. We tend to believe that if the user does not get excited with the initial core value of our product, then we should add “bells and whistles” – more features (in the good case) and cheesy graphics (in the bad case). This is all wrong. Initially, we should focus on the core and the core only. If the core does not provide substantial value, then we should refocus and look for another core. This is a very difficult thing to do, since at times it requires a complete change of the company, and not just pivoting as some like to say these days.

Examine your product, the way you talk to your customer and the customer response. If you need to explain a lot and discuss many use case scenarios in order to show value, maybe something is materially wrong. Maybe you need to search for another core.

7 thoughts on “Core vs. Features

  1. I totally agree. We have learned over the last few years that there are a few methods for this. They sum up into two buzzwords but are very profound if you take the time to really understand them.
    1. Win the user first – this comes from the fact that the best software is the one that gets used the most, hence provides the highest value to the end user.
    2. Robust Simplicity – Information systems often need to be complex to perform their tasks. If you make sure to keep a high tension between the robustness of your application and yet make sure you keep it very simple to use, you will have your winning proposition that will support statement 1.

  2. This is funny, last week I presented at a Microsoft event and one of my key messages around where the focus of Business Process Management & Modeling needs to start: The CORE of the business (e.g. Insurance: Underwriting).

    I am happy to see we still think alike

  3. I think that Minimum Viable Product is the gate at which a company needs to launch its offering, not necessarily a business oriented goal but rather a user adoption/value goal. I know a couple of companies that insisted on developing “Everything” before launching their offering to the public only to discover that their VC money has gone down the drain on the development that is very different from what the market and the end users are expecting/needing/wanting.

    Launching a minimum viable product gives companies the ability to get real feedback from real people with real needs. This is priceless for a company that is trying to change the way things are done and may be caught up in it’s own vision that they fail to see the gap from their belief to reality in the market.

    1. I agree with Sharon. MVP and Core/Features are similar, but not the same. Core is the very essence of your product value. MVP is about the minimal capabilities of the product that you can release in order to get valuable customer feedback to your offering. It’s the difference between “what” to “how”.

  4. MVP has its own risks. It is hard to tell wether your product is “over the minimum” before getting enough honest user feedbacks.
    So, my 2 cents: MVP launch should be accompanied with support & development resources to assure tangible slack above what actual end users consider as minimum.

Leave a comment