Software Product Heroes Learn From Their Purchase Regrets – Part 2

Part 2 – Don’t Embed the Wrong Vendor Twice

In this article, Part 2 of our three-part series on the challenges of software purchase regret, we’re discussing how to avoid making the same mistakes twice. Once you realize it’s time to replace the solution you purchased, it’s critical to understand what went wrong in the buying process in order to avoid it in the future.

Don’t be dazzled by any person or company. 

The Problem: Unfortunately, the old adage “No one ever got fired for buying IBM” still lingers today. It is easy to get enamored with large companies and believe that their size or large recent fundraise will have a correlation to your success. It may even feel like a safe choice. However, for a lot of these analytics vendors, embedded solutions are an afterthought. For example, analytics companies have built their product and organizational structure for enterprise use cases (and some of them are good at those use cases) rather than for embedded use cases for SaaS products. They just expect customers to deploy an army of developers to jam that square peg into that round hole. Salespeople believe the hype and will focus on success stories while ignoring what could be warning signs the solution isn’t right for you.

Ultimately, this puts the onus on you to truly understand what your customer wants, what your customers will actually use (and pay for) and if what’s being positioned is the current or future state of the software. 

The Solution: Go into any purchase process with an understanding of what is critical, what is nice to have and what isn’t necessary and stick to your list. While having holographic charts which render your stock portfolio in 3d inside the metaverse might demo really well and seem compelling – it’s just not something the market is ready for and something that shouldn’t influence your decision. So, choose a company that understands your use case and pain points, not just one that plays in an adjacent space.

Make Sure it Connects to your Tech Stack (and data)

The Problem: During a sales process, vendors will say API as if it’s an easy button to integrate everything in your tech stack. That’s simply not true. Data especially comes in different forms, is organized in different ways and has a variety of security-related conditions. New data sources are added often and times customers want to bring their own data as well. This result is never a one-size fits all answer.

The solution: Conduct a comprehensive proof of value, proof of concept or pilot. Any company wanting to ensure your success will be more than willing to commit time and resources to ensuring you make the right decision. During this POV rely on real data and data structures to fully embed a module of the offering into a sandbox version of your software. If you run into any hiccups along the way (and you will) vet the support center, articles and community to understand how easy it is to resolve issues.

Thoroughly Test White Labeling Capabilities

The Problem: White labeling – the ability to match third party software to yours – must go beyond colors and fonts. Instead, modern applications must deliver a consistent user experience, transitions between experiences and a wholly infused approach. The end user should never know third party software sits within your application. However, many legacy vendors aren’t built to allow for this and instead offer rudimentary white-labeling leaving you with a frankenstein application.

The solution: Understand what makes your application unique. Involve your designers, UX experts and developers to not only embed capabilities which integrate into your backend but also seamlessly integrate into your front end. Test these capabilities with your end users on staging environments or via sites like UserTesting.com. Assess how easy it is to make updates, how far you can go and how software updates could impact any customizations you made. Only then will you have the confidence to believe you’ve found the right solution.

Conclusion:

Once you’ve completed a thorough pilot process you should ask the vendor for a reasonable implementation timeline. Based on their knowledge of your tech stack, data structure and other customization requirements they should be able to provide you with a reasonable estimate on implementation timing. If they’re unwilling to do so, that should be a warning sign that you missed something in the vetting process

In our final part of this series, we’ll focus on how newer, modern vendors are innovating to deliver embedded capabilities for the SaaS generation.

In this series…

 

Popular Posts

multi-tenant analytics

Why is Multi-Tenant Analytics So Hard?

BLOG

Creating performant, secure, and scalable multi-tenant analytics requires overcoming steep engineering challenges that stretch the limits of...

What is Multi-Tenant Analytics >

How We Define Embedded Analytics

BLOG

Embedded analytics comes in many forms, but at Qrvey we focus exclusively on embedded analytics for SaaS applications. Discover the differences here...

What is Embedded Analytics >

embedded analytics for startups

White Labeling Your Analytics for Success

BLOG

When using third party analytics software you want it to blend in seamlessly to your application. Learn more on how and why this is important for user experience.

White Label Analytics >