Products are not services

Someone walking across a dangerous rock

▲ Photo credit Gemma Evans on Unsplash

We've been working with a consultancy service business, who want to diversify and launch a technology product. They've spotted a great opportunity from their consulting activities and so far we've been helping them to build their product strategy. As we've worked with them, we've been reminded of the differences between service and product thinking.

Start simple

There is a long running trend in skills-based service sectors to elevate work that gets done, with complex language and concepts. In some part, this is due to the nature of communicating a process and deliverables, but the cynic in me suspects a bit of opaqueness helps to justify the use of external help and additional costs.

This approach is generally not helpful in defining, designing or delivering products though. To stimulate interest and excitement in your product, it has to fix a significant problem for people with the least amount of investment of their time and energy. Your intended audience should 'get it' without the need for explanation, tutorials, etc. If they're sitting there think that's great, but I don't know when I'm going to get the time to learn how to use that, it's probably not going to fly.

When you are pitching your idea to prospective customers, start simple.

Get simpler

That's not the end of it though. If you're going to build a prototype to get feedback on your product concept (and you should), you should look for more opportunities to simplify. You will undoubtedly hear, "this is great, but it would be great if it could also...". We'll come back to this in a minute.

What you should look at with a laser focus, are areas of the prototype where you audience spends little time or shows only passing interest. These represent opportunities to simplify your product further. Also, look out for signs of uncertainty. Complex concepts, multiple options, configuration, etc, introduce cognitive load and get in the way of getting a task done or enjoying an experience.

Not only will this approach make it easier for your audience to engage with your products, but the saving in time and money can be used to make the core elements shine or in building your message in the market.

When your testing your concept, look for ways you could make it even simpler.

The right to say maybe

One of the biggest changes for a service company, is learning that it's okay to say "maybe". Like most successful services, our client partner is used to accommodating request that their clients have. After all, providing top notch service, being close and supportive, is what great service is all about.

When you decide to build a technology product, you're taking an oath to be the custodian of it now and in the future. You determine the vision and direction your product takes. As custodian, you should listen carefully to your audience, consider what they are really asking for and why, appraise it against your vision for the product, and only then say, "maybe".

If this makes you feel bad, don't, because it's a compliment. What they're usually saying to you is, "I love the how your product solves my problem. I'd like you to solve more of my problems, so I don't have to use this other crappy software." That's great; they appreciating what you do, but remember, you're the custodian.

Sometimes, they may have actually spotted an actual gap or issue in your solution. You'll know this, because you will hear it multiple times and expressed in different ways. Your job as custodian, is to sort the wheat from the chaff, then find the best wheat, and then make heavenly bread!

You're the custodian of the product - you have the right to say "maybe".

The cost of saying yes

Another way to look at feature expansion, is the cost associated with new or additional features. There are two groups who pay this cost; your users and you.

From your users perspective, whilst new or additional features may add value to them, they certainly add cost in terms of cognitive load, UI performance, training, etc.

From your perspective, new or additional features have an upfront cost in design, engineering, testing, documentation and deployment. They also have an ongoing lifetime cost in terms of support, maintenance and complexity for you engineering team. Saying yes, more often than not leads to increased complexity and reduced quality.

By accepting every request for new features, you're heading off in the direction of 'Enterprise Software'. Yuk.

Summing up

If you're a founder that has seen success as a service provider, it's worth thinking about how this will impact your product decision making. On the one hand, you will have great insight into your sector and the key challenges. You should also have empathy with the key audience groups. These things are great.

Be aware though, you might have to fight your instinct to say yes.