Attribution: Today’s post is inspired by a lesson I recently learned from Dr. Dwight Porter, President of Applied Decision Resources and all around business genius.  I’m very lucky to study under his tutelage.


Imagine for a second that you (the reader) and I just started a brand new tech company.  We’ll call it Andrew and Jon’s Technology Company (I’m going to refer to you as Jon, just play along).  The first thing we do is draw up a thesis on what the company could be, maybe we raise a small amount of money from friends and family or angel investors and then we hit the streets trying to sell our software.  For the sake of this exercise let’s say we’re building a software application for corporate instant messaging.  Our value proposition is that unlike current players in the market, our app lets you view group chats in a threaded pattern (big weakness of current apps in the market, like Slack).

To start, we’ll have zero customers, a work-in-progress messaging platform, and no revenue.  Our immediate goal is to land our first customer – someone who believes in us and is willing to bet on us.  Chances are we’ll pitch dozens of prospective customers before we find a single company who will buy anything from us.  The first 30 companies we talk to use Slack and don’t have a need for anything more sophisticated or different.  However after weeks of searching for a customer, we do find a security company called Security Inc. that has a special unmet need.  They need a messaging app with a very high level of security.  Well – it’s a little different than our business plan, but these folks are willing to pay us, so why not give it a shot? 

At this point, our “product map” looks roughly like this:


In exchange for being our first customer, Security Inc. has lots of custom requests and expects a heavy influence on our product roadmap.  At this point, we’re willing to do just about anything, so we sign Security Inc. as our first customer and commit to all of their requests.  After the deal is signed we spend the next several months heads-down just trying to meet their expectations.

If we’re lucky and work hard we’ll have delivered the secure messaging app on time and have satisfied our first paying customer.  After a short breath of relief, the next thing we’ll do is go out into the marketplace and look for other customers that look like Security Inc.  Since we’ve already built the secure messaging app, the easiest thing to do is sell what we’ve built to other customers who also need secure messaging.  If we find that there are a lot of other customers out there who look like Security Inc, then we’ve just created our first “product offering” and our product map will look like this:


We still have a single messaging platform, but we’ve now defined our first product offering that we’re calling “Secure Messaging”.  We’ve matched that product to two customer segments that we think will buy our software: Security Firms and Private Detectives.  We put our eyes toward scaling the business and hire a sales person to sell Secure Messaging, we teach her the sales pitch, set a sales quota, and set her loose on the market.

As founders, you and I now go back out into the market (with a little bit of a spring in our step) to look for what else we can develop for prospective large customers.  Before too long we find a customer, Mobile Inc., who really needs a messaging app built for the iWatch.  It’s a huge customer – much bigger than Security Inc. so we decide to take a chance and commit to building the iWatch app for Mobile Inc.  Again, we put our heads down and deliver for a big strategic client.  Then we look out into the market and see who else needs our iWatch messaging app.  If we find that there is a market, we update our product map as follows:


However, as we go back to our current customers, we find that our existing customer segment, Private Detectives, also need the iWatch messaging app – what good fortune!  We can now upsell them to use both of our products.  Now our product map looks like this:


We hire a sales person for iWatch Messaging, teach them how to sell, give them a quota, and then we repeat the process.  You and I (the visionary founders) go back into the field, always pushing the boundaries of what we offer, then packaging it into a product offering for the team to sell.

A product offering is a group of platform features that work together to deliver a specific value proposition for an end client.  That offering can be named, marketed, priced, sold and serviced.

As our company matures we are always out in the market selling custom deals to “whale” sized clients, and then packaging the capabilities we build into product offerings for our team to sell and scale.  Over time you and I will sit back and look at the beautiful portfolio of product offerings we have built.


What is a Product Offering?
Tagged on:         
  • That’s very nice, and clear. Thanks!

  • Harley Norrgren

    Nice one Eifley, as a visionary business owner with limited development resources, how do you balance the evolving needs of your existing clients with the allure of the next big feature to develop for a new customer base?

  • Harley,
    Great question – unfortunately I don’t think there is any one perfect answer to this question. I think it really depends on your business situation – however in general I would expect that early in the life of a company (startup phase) that the majority of the time is spent on “custom.” As the company matures and grows out of being a start up, the ratio flips and the majority of the time is spent on existing products. Hope this was helpful! Thanks for reading.

  • Bren Eifler

    Great examples! I have often thought about this process and seldom have I seen a more practical and concise explanation. The graphs really help. – Question: How would this process change if one was marketing to “fish” size clients and waiting to get customers until they had a production ready release? Would they use focus groups to ensure they were building the right product?

  • This is a really good question. I don’t have as much experience with that approach, but my best recommendation is to get the product into customers hands as soon as possible – in whatever form you can. If you’re creating a UI, create a “paper prototype” – literally draw the UI on a piece of paper, or create the design elements by cutting out pieces of paper – then show that to customers. Don’t write any code without getting explicit validation from multiple customers that you’re building the right thing.

    Another fancy trick here is to ask customer to pay for your product upfront before you’ve built it. This helps separate the people who seriously need your solution from the ones who just don’t want to hurt your feelings. If you find someone who’s willing to pay upfront – then that’s a pretty strong signal that you’re building the right thing.

    The biggest thing you want to avoid here (and what happens 95% of the time) is building something based on a grand vision that you have, that ultimately does not meet the needs of what your customers need.

    Also – be careful of the “one more feature” fallacy. Sometimes when you show your prototype to a customer they will say “if only you added this one more feature”… this very often is a wild goose chase of endless “one more feature” requests. Focus on the minimal viable product that meeds that burning need that your customers have – once you’ve nailed that core need – then you can expand out and build more features.