by Varsheni Sundar | Dec 25, 2020 | Presales
Use more analogies in demo and presentation. Why? A well-crafted analogy will help convey the value of the solution with ease. It helps the audience remember the ideas that were presented during the demonstration/presentation.
It is vital for a Solution Engineer to resonate with their customer’s requirements and pitch their solution with the help of a story or an analogy.
What is an Analogy?
An analogy is a form of comparison to provide a better explanation for a point. A common analogy everyone recognizes is “Mary had a little lamb. Her fleece was white as snow.”
Why use an Analogy?
During presentations, I have come across many solution engineers explaining features which the potential customers were never able to relate to. They leave confused after listening to the presentation.
Some Engineers improvise by sharing statistics. However, customers tend to forget these stats once the presentation is done. They don’t carry anything useful.
Hence, analogies during a presentation helps your customer remember a story which in this case is the story of your product. The key idea is to present an analogy that fits your story, which the customer understands.
A Few Analogies
Here are a few analogies that I have used based on my current experience in presales.
1.“Forums are like Facebook: Customers can share their views or voice their opinions as a post and viewers can reply to the post as comments. So it is one to many communication channels.”
Everybody knows Facebook. So, it becomes easier and memorable.
2. Channels which users can use to reach support to help solve their queries are like Transport: It facilitates movement from point A to point B via different media. Here the transportation media could be Facebook, Email, Twitter, etc..but the information (issue) should reach you (support staff).
3. Audit logs – The word “audit” means “to hear”, logs means “record of the event”. The audit logs are like the history of events that happen in a day/month/year.
4. SLA – The SLA is like an “alarm clock”, where you can set the deadline. If the time hits, then it will ring so loud.
5. Automators – The automators are like “automatic cars” when you put the key and start the car and the gear is in the drive mode, the car automatically moves. Here, “starting the car with the key” and “having the gear on the drive mode” are rules, which automatically leads onto the car movement.
Since there isn’t a single analogy to fit every situation, the key is to adapt our analogies to fit the scenario in question. And, it’s important to change analogies over time as well.
More on related articles, check this link
by Mukhil Maran | Dec 1, 2020 | Technical
In our last blog, we discussed the three reasons why SaaS will dominate the future. With no time wasted, let’s look at the 3 vital steps build a SaaS product.
Market Research.
Market research plays an important role when we want our idea to be executed in a seamless manner and for a long run benefit. Performing a market research will give deep insights about the market, reviews of the competitors’ products, what the customers need from the present vendor and what they are not giving to customers. Insights like these will definitely help decide whether to take the idea forward for execution or not.
Market research helps you identify what your customers want over what you have.
Defining and developing.
Once the market research is done. Once the report from the market research is positive, we need to define a clear plan for the SaaS product we are going to build. This plan should contain the programming language, tools, framework, and last but not least UI. While we met the technical aspect now, we should make sure what exact buyer persona (which market research would have denoted).
This targeted buyer persona will help us understand the problems they are facing. The more big and clear the problem is, the more chance for us to give accurate solutions.
After defining comes the development part. We can either have an in-house development team to build the product or collaborate with an external agency that can do it. Just keep in mind the plan meticulously explained to the development team and they keep that in mind.
Remember, neither YOU nor I can save the product if the UI is bad.
MVP or EVP Strategy.
During the build of the product, we should choose which strategy we are going to adopt. MVP or EVP. MVP stands for Minimum Viable Product. EVP stands for Exceptional Viable Product. The difference between MVP and EVP is that in MVP strategy, we will be developing the product at minimal costs. It is not exactly a full-fledged product but nevertheless, not less than that. It’s playing the game safely keeping the costs minimal in development, test the viability, get feedback from closed group (this group can be your target persona)
In EVP strategy, we will have the product developed completely to go live in the real market. The risk factor is high as the customers may turn down the product’s arrival in the market. If the welcome turns bad, then the huge amount invested is burned in no time. If we’re very confident about the product, or if our product is a new entrant in the market that tries to solve a big problem, then we may opt for it.
It’s all about identifying a sweet spot. Whichever suits our business, our financial capability we may go with that.
Closing thoughts.
One thing we should keep in mind is, there is always a room for innovation. In this era, everything is invented. The real entrepreneur would always identify pain points of the customers using or consuming a product and try to bring that new element along with all existing elements. In SaaS business too, we should look at what we can innovate that would give superior customer experience as well as customer satisfaction.
In this era, customer satisfaction is just normal. Customer experience is the norm
