¶ Disclaimer
The work of discovering a system for USP creation was made in a group collaboration within internal research of "J-IT" Diestleistungs GesmbH (In this disclaimer: "the company"). Our purpose was to collect internal knowledge and create USPs according to any possible solutions that we are able to provide to our existing and potential customers. I (Nejc Grenc) have led the project from start to finish, but I recognize that the credit belongs to the complete team who put in hours of work to get this system operational.
The following system description does not contain any private or sensitive data of the company. All the examples are fictional and do not represent actual efforts or customers of the company. The following document contains only the detailed general description of the USP creation system, which is published with verbal agreement as a non-profit free-to-use article. This also does not represent the company views and I, as the writer, am solely responsible for its correctness.
¶ Introduction
¶ What is a USP
USP stands for Unique Selling Proposition
”The USPs job is not to convince people to buy your product. Instead, its job is to act as an anchor in your prospects’ (and even customers’) minds. You know how you can read a book and just two weeks later, all you can remember are some of the core concepts? Your industry visitors experience the same thing with your website. They won’t read all of it, to begin with, and they’ll forget most of what they read within hours. The USP is the one thing you want them not to forget." (Caleb Demel)
First of all: A customer has a need: For example, an IT department is running out of software budget but has to integrate additional data storage processes. Do they know their needs? Sometimes.
As an answer we fulfill the need and create value for the customer. If (the customer thinks) we can do it better than the competitors, they will very likely choose our solution and that it is economically reasonable for us we have a…. USP, a Unique Selling Proposition!
Take away: It’s what makes our company different from everyone else.
¶ This page
This document is structured in two parts:
- Sparking USP Ideas
A blog of the thought process of aproaching USP creation from a perspective of a developer. - USP Creation Mechanism
Direct and dry description of a process flow.
I recommend reading from start to finish, but if you are interested only in the final process, feel free to skip the story in the first part.
¶ Sparking USP Ideas
The following blog story represents personal struggles and solutions of the author in regard to creating USPs. It may or may not be directly applicable to other similar situations and struggles of others, but in any case it provides a valuable insight into a problem-solving strategy, that can be used for creation of USPs and similar creative works. The following approach is specifiaclly focused on the very first part of USP creation: identifying a USP. I will skip the latter parts of condensing a USP into a slogan and its marketing approaches.
¶ Abstract
USPs can be hard to create for more technically oriented people, since USPs are meant to increase interest in prospective clients and are therefore not written in a techincal way. Luckily, USPs can be built by generating a lot of ideas and then filtering them to meet USP requirements, in a series of well-defined steps, that are tunned especially for such technically oriented people.
¶ USPs are hard!
If you are anything like me, you perhaps find creating USPs almost an impossible task.
Through the years of practising and conditioning in my studies and later in my career path, my mind has become extremely development oriented. I can be given a problem and I will do everything in my power to solve it. I will solve it perhaps alone, perhaps with online literature, or perhaps even by bringing in other people with better skills on the particular matter. Eventually, though, I will always be able to answer with a solution (or at least a progress report) to the presented problem. Do not get me wrong, this does not mean I have become a lateral thinking machine. A lot of problems require creative solutions and those are not out of my reach. However, I find myself struggling when I am required to produce a solution without being given a specific, well-defined problem.
Creating USPs is in my mind a task that does not have a good underlying problem. We can form a question from the side of a customer like: “Hey, what is unique (1) about you that you can sell (2) to us?”. This is definitely not well-defined. It is simply much too broad of a scope for me to tackle. So broad, that I have spent hours in introspective, thinking of various qualities, talents and skills, that an average Joe in our competitive company does not have. While some of my personal unique qualities, that I managed to find, can become quite absurd - one of my unique skills include making coffee while holding a phone and reading instructions through Google Translate - those are definitely not sellable.
In this blog, I will describe my plan to strategically search for USPs. Unfortunately, there is no automatization possible for this task, so it is still necessary to spend hours on introspective thinking, but I am sure that my plan will help guide thoughts towards more viable solutions - more viable USPs.
¶ Your personal USP
Before you create USPs for the company, you should first focus on creating your own personal USP.Focus on your own abilities and not try to take the whole company into account. Try to think what "you" can do, not what "we" can do - sometimes taking into account the whole company can be too restrictive for a good idea-flow. After you are done with your personal USPs, you can consider whether they can be used as USPs for the company as well - after all, you are part of the company and your abilities are transitively company's abilities as well. Or consider creating new company USPs with your newly gained experience.
If you get stuck, try to create a USP of yourself that you would offer to your company. Consider what of your skills and how your company can use / is using them.
Creating a USP at once is a difficult task, especially because of the amount of requirements they contain. A USP needs to be (1) Unique, needs to (2) sell and needs to be (3) a valid proposition. It can be a daunting task to create a whole USP at once, especially without a lot of experience in the matter.
¶ Introducing a UVP
My suggestion is to instead focus on a more familiar and easily attainable concept: UVP - A Unique Value Proposition. Similarly to many definitions and descriptions variations that can be found in regard to USP literature, the UVP is not uniquelly defined (examples: USV, UVP). Very often it is used as a synonym for USP. For the use in this blog, I want to point out the main difference between a USP and a UVP. The UVP focuses on the inherent value of a proposition and does not care if this proposition can actually sell and whether any money can be made from it. It simply focuses on what can be made or provided (source and detailed reading: UVP vs. USV). As you will see later the UVP will serve as an easily attainable stepping stone towards a USP.
Recap UVP vs. USV
In the short article, the author associates UVP and USP with a concrete question from a potential customer, which can realisticly occur during a sales meeting.
UVP - a customer asks "What do you do?"
UVS - a customer asks "Why should we care?"
UVP is a statement about who we are and how we want to be viewed as. A USP takes that solid UVP and puts it into a language that speaks directly to your target market. It comes from listening to the specific customer’s needs, so it is not uncommon to have multiple USPs per UVP.
¶ Decomposition
Arguably, in the previous section, I just swapped one hard to achieve concept (USP) with another (UVP). Let's take the latter and focus on each of its elements separately - in other words, the UVP is getting decomposed (Decomposition).
In each step of decomposition I limit and refine the proposition statement further.
¶ P - Proposition
A dictionary (Proposition) describes it as a business offer or a suggestion. It can be a simple statement meant for informing target audience about various possible things that you are able to provide.
In the first step, create many various propositions. Anything goes! Afterwards, many of these propositions will be filtered out. You can create many more afterwards or refine and expand on them. The more propositions you make, the better.A good start is to write sentences starting with "I can...". Again, start by focusing on your own abilities, before considering abilities of the whole company.
In this example, I introspectively consider my various abilities.
- I can make a good cup of coffee
- I can develop a quick running service
- I can organize a working desk very well
¶ V - Value
The plethora of propositions need to be evaluated whether they provide any business value to potential customers. Filter out or refine your potential propositions to contain at least some amount of business value.
Continuing the example, I remove the coffee, since we have machines for that, and desk organization is considered a very common skill. Also, I refined and expanded on my ability to program services.
I can make a good cup of coffee- I can develop a quick running service
- I can create well tested services
- I can program in Java and know Spring
I can organize a working desk very well
¶ U - Unique
Now comes the difficult part. Most value propositions are quite common and many people can have the sufficient abilities to provide them. Now, filter out the ones that other people, especially your competition, can easily provide. Only the ones that are your unique abilities should remain.
Do not be too strict to yourself. There are billions of people in the world, so there is a chance that you will find no single thing that is completely unique to you. In the words of an Internet meme: "No matter how good you are, there is always an Asian kid better than you." You just pick the propositions that are sufficiently unique to you compared to your peers.
I have a lot of well defined programming skills, but those are quite common in the IT-development community.
I can develop a quick running service(simply the speed is not unique quality)- I can create well tested services (extensive testing)
I can program in Java and know Spring(those programming languages are quite common)
Through my years of working in this industry, I have seen a plethora of unreliable programs. Testing is quite rarely sufficiently made, even though in today's programming industry it is almost a requirement. Not to mention that TDD (Test-Driven Development) paradigm is really scarcely followed. Being able to write tests well can be thought of as a sufficiently unique skill.
There can be many more UVPs created this way, but for the purpose of this example, I will focus only on this UVP: I can write well tested code.
¶ Converting UVP back to USP
Last part is the hardest in my opinion. The business value proposition needs to be enhanced with a marketing perspective. Here you need to put yourself into minds of potential customers. Consider how can your UVP improve your potential-customers' lives and rewrite it from that perspective. You should end up with a USP.
In my example, the main business value of tests is that it makes the code reliable. Well tested code means that it is less error prone and less likely to break down and overall work reliably in various situations. Also, very importantly, the tests are some form of proof that the code actually works - "How can we know that the code actually works, if there are no tests to prove it? (a common TDD quote)". In this situation we will focus on these two descriptions “reliability“ and “proven to work“. These terms are somewhat emotionally charged as they represent a feeling of calmness and security. As such, they are rarely used by developers and are in my mind considered more like business lingo.
With all that in mind, a USP could be: I write a reliable code that is proven to work in every situation.
¶ Returning to the company USP
Now you have created your personal USP. This USP is definitelly relevant for you, but might or might not be relevant for the whole company. Our ultimate goal is to create a company USP, so we have to analyse it from the company’s perspective. As you are part of the company, your skills are also skills of the company, so your personal USPs are very likely to translate into company USPs well.
This is quite easily done by setting up a meeting and discussing the applicability of your USP to the company along with other teammates and employees. The more varying the group, the better review of the proposed USP is possible.
A very smart move going forward is to check how other companies create their USPs. There are tons of examples on the internet (like this one: 7 USP examples). Be aware that terminology might vary.
¶ Top it up with a slogan
That is all for our part. You now need to fill in the USP formular. Keep in mind that there is not need to create a slogan as well or further improve on the marketing perspective of your USP.
However, if you were to pursue the USP to the end, a good next step is to create a slogan. An OK slogan could be: Writing tested and reliable code. Perhaps an even better one: Code, proven to work. Simple as that. When creating slogans, simplicity is the key. However, this is out of the scope of this blog, so better go check some other guides for that matter.
¶ Improvement: Customer-side approach
The above approach is a solely developer-focused approach. Its flow is entirely from developer towards customer, meaning that we start from a set of developer's skills and work our way towards making these skills interesting for customers. This approach is aimed mostly at businesses with none or barely any prior customer experience.
However, if the developer already has some customers or clients, it can be very prudent to try from their perspective as well. Retrospectivelly investigate our existing customers and approach from the Selling side, from the side of the needs of the customer.
Try to answer these questions: What is the pain of the customer? How are we already helping there? And what more can we help with?
This should be of course trated as an addition to the developer-focused approach above. Not only should we focus on own abilities, but guide them towards the customer needs, we have already identified in our exisitng customers.
¶ Improvement: Combine propositions
Do not actually cross out the propositions.
Instead of crossing them out, move them to another list. A single proposition might not be very valuable or unique on its own, but it might shine in a combination with another proposition. Our personal skills are not exclusive, so neither are our propositions. Try to combine them in interesting ways and see if any USPs can be created this way.
In the example above, we removed these propositions
I can organize a working desk very wellI can develop a quick running service
However, with a pinch of creativity, we can combine them into a I can create an organized environment and develop quick organized services, that run well. This new combined proposition has again a great possibility of becoming another USP.
¶ Recap
Creating a USP is a difficult task for someone with relatively little marketing experience. It requires a mindset and exercise in introspective that is not quite common in my line of work. However, applying the short USP algorithm that is described in this blog, can turn out to be more familiar to a development-oriented brain. It helps to compartmentalize the task of creating USPs and splitting it into subtasks, that can be tackled one at a time in order. The USP is then gradually built with more and more fine-tunning of the USP description.
My brain is trained and wired in a way that I am not accustomed to the buissness terms, which is a big hindrance when trying to create USPs. This algorithm surely helps me out. It is not guaranteed that it will work for you as well, but I urge you to give it a try nonetheless.
¶ USP Creation Mechanism
The following description process was created as a team effort with other developers and it describes an innovative process for creating USPs on mass.
Our team does not have a single gimmick that would build the core of our group. Instead, we are a group of individual developers that have little in common and mostly just work on projects and tasks that are contracted to us by our customers - pretty much like all the other contracted companies by each of those customers. This individualism and uniqueness of tasks gives us a hard time for identification and creation of USPs. Each person works on different tasks, and therefore it is quite impossible to find some unique skill or feature that would make our team coherent and stand out. Instead of giving up, we went in another direction - we decided to look into our own personal skills and from there build the core of our USPs. Our unique features that we ourselves offer to the team in general, can be in turn offered within this team to our customers.
¶ 1) Identifying skills
During our intense sessions and refinements we came up with the following guide how to create the building blocks for our USPs:
- Each developer performs internal introspection to identify their personal skills.
- Each skill should be written down. The more, the merrier and no idea is bad, since each can be useful later on.
- This produces a plethora of skills that are kept in a backlog.
In a brainstorming meeting, the skills are identified and potential useful sets of skills are combined, which form arguments.
¶ 2) Arguments
Skill for creating SQL queries and skill for creating REST calls are not very unique on their own, but if put together, they can enable us to create applications without middleware - in essence, direct frontend calls to database, like Oracle’s REST API technology. Each such combination of skills is called an “Argument”. It is fairly unique and valuable and cannot be easily identified in our rivals, so that it should be considered for a potential USP.
¶ 3) Stories
Developers describe the argument with a story.
A story is written for each argument. These stories depict possible usage of these arguments in practice. They usually build upon a past experience with working on projects of our existing customers, where these arguments came into play. The main goal of these stories is to paint the arguments in a light of usability and in this way present their practical ways to the marketing team. Marketing need to fully grasp the idea behind each argument if they wish to present it to new potential customers as a service we can provide.
¶ 4) Marketing → USP
An argument with story is sent to marketing team for USP creation.
At this point, the Marketing team comes into play, with their unique knowledge of customers and ability to market our arguments. The arguments along with accompanying stories should be enough for Marketing to enhance them with ability to sell and expose their uniqueness - and in this way, they should have sufficient information to create fully-fledged USPs.
In this interface, we do not really create USPs. The main argument behind that is that we do not really have much interaction with customers - the Marketing team does this interaction for us. Most of the time we, as developers, only receive fully fledged requirements that we only need to implement. Therefore, we came to an agreement to do our best to provide the building blocks in form of arguments and stories to the Marketing team to do the final building of USPs.
And boy, with this system in place, we can create a plethora of arguments.
¶ Database USP Creation Example
We performed these exercises in each of the teams separately and created 3 arguments with 3 stories. We could have created even more of them, but for the initial purposes it was enough.
Let me now quickly present the argument and the story from database’s team.
We started with the following list of skills:
- I know how to work with data
- I am familiar with both most RDBMS and Kafka
- I know how to extend SQL with user-defined procedures
- I can work with most data serialization formats inside database (CSV, XML, JSON, …)
- I know how to integrate different data sources between each other (dblink-based, file-based, kafka-based)
These skills were combined into a unique and quite valuable argument.
We can create reliable and fast data integrations pipelines between different kinds of data sources, such as file systems, SQL and NoSQL databases and Kafka.
Inherently, this is sufficient for us. However, this can be quite hard to understand for the marketing team. To better explain this argument to them, we created the following story
One of our customers went away from their existing one-size-fits-all system, and moved towards having many small specialized services instead. With this new approach, working on only one single database is no longer feasable. However, having the individual databases communicate with each other usually requires extra software layers on top, which are expensive to develop and maintain. Thus, the client wanted to find a way to integrate the databases behind the smaller services (plus the existing big database) with each other directly. By integrating the old database as well, all old systems which only have access to this one data source are indirectly integrated into the new architecture as well.
To achieve this, we proposed a solution using Kafka, an integration tool which makes it possible to have direct data transfer pipelines between systems. We first created a proof-of-concept, then assisted the customer throughout the design process and finally implemented it into the actual microservice.
We have the technical know-how to be able to work with many existing systems, while also being trained in upcoming technologies like Kafka. Thus, customers don’t have to find and design solutions themselves, before handing them over to us for implementation. No, instead, customers can come to us with the problem directly, and we can not only just find the right solution for them, but also offer to implement it as well. This eliminates a lot of friction, since the same people are present during each step, from solution design to implementation.
This is the culmination of our work. Afterwards, the argument and the story was sent to marketing team, who along with our managers, examined these arguments and stories and see if they actually fit the requirements of our USPs and can actually be used in convincing our potential customers to choose us. They came up with the following USP
¶ Proposed USP
We have an incredible knowledge of industry-relevant software solutions in use. This enables us to find more then one solution to integrate customers data sources into a working pipeline.
¶ Conclusion
During our sessions we have created a ton of skill descriptions, which lead us to create many more arguments and stories which can lead to many new USPs. The main goal that we achieved in our work here is not the actual arguments, stories and USPs created, but instead the system that allows us to pay attention to our skills and regularly and reliably churn out new USPs for the company. This system is the main solution that we delivered through our work and I hope that we will continue using it in the future to create many valuable USPs for our company.