Avoiding the Vertical Product Trap

In a previous post I wrote about the differences between vertical software (which solves a specific industry niche requirement) and horizontal software that solves a problem (however small) many industries have.

The fundamental challenge with vertical products is keeping them fresh with ongoing investment. A well executed vertical product has a clearly defined market. Once it reaches a reasonable level of penetration it will fail to generate significant new (e.g. sufficiently exciting) revenue growth.

It’s not that the product is a failure. Rather it is mature with limited growth opportunity. With declining growth it’s natural to want to maximize margin. The owner will look to reduce ongoing investment to a level that maintains subscriptions and not so low that customers are lost. Common tactics here include outsourcing, moving key staff to other projects etc.

The trap is that few products are built on thin air. The products exist on underlying technology platforms that rapidly change. Mobile apps experience this cycle rapidly: think of an app last compiled for iOS 3: It might work on iOS 14 but it would look and feel terrible: a combination of new and old UI, no support for retina display, letterboxed layout, etc. Without modernization the app will attract bad reviews, attrit users and generally languish.

Of course, web based apps don’t age so badly. A web app built in 1995 will likely render but be built on a set of technologies like cgi-bin that few would want to touch. Customers might attrit, but slowly. The nature of this slow decline means that business attention tends to be elsewhere until the product frog is truly boiling or a competitor appears that causes rapid decline.

So if that’s the trap, how can you build the product to slow the fall? It seems to me there are a couple of key ways:

Don’t build what you don’t need to

The smaller your code base the cheaper ongoing maintenance and updates will be. The goal is to build your unique value proposition and integrate with best of breed solutions for everything else. Be it use of PaaS platforms or more functional pieces.

For instance, nearly every product needs authentication. But do you really need to build it? Building authentication looks easy but is a lot of work do to securely. Might it make more sense to piggyback on other platforms like Sign in with Apple or Google Sign-in that handle all the security issues for you?

Similarly once you have some enterprise customers you’ll be asked to add reporting. Does it really make sense to build that? You could embed PowerBI or implement OData so that customers can build their own reporting.

Another common use case is the need to build user and group management in a product. But here’s the thing: enterprise customers already have feature packed user directories built on tools like Azure AD. Just implement SCIM and let your customers users and groups flow through.

Ignore your architect, embrace lock-in

Speaking of PaaS, many software architects will advocate for building the product cloud neutral in an effort to avoid lock-in to a particular cloud. You’ll hear talk of Kubernetes and containers. Push back: lock in has costs but is unavoidable at some level in your stack.

Instead, embrace solutions like Azure Functions or AWS lambda in the top tiers of your application and let the cloud vendors tackle difficult enginering challenges like scale and replication. Use PaaS datastores like Cosmos DB, not your own instances of Mongo. In the long run you’ll incur additional costs but these are good problems to have: it means you have volume on your product and can make cost savings through targeted optimization. The key is to understand where in the stack is your unique IP that defines the product and ensure that is encapsulated in a way that it can be moved in the future.

API Led Development

Having said ignore your architect, this is one place where you should really listen: A well designed API provides enormous benefits to any application by separating user interface from implementation. But it’s not frequently the first thought when building a product: ‘we’ll get to the API later’. This is a mistake for a couple of reasons:

1. The API permits user interface and back end development to move at different paces. Put another way, it’s much easier to freshen the UI if it’s not deeply intwined with the back end.
2. When a customer asks for an API you already have a starting point.
3. Embedding partnerships (where your product embeds in another vendors product) become viable
4. Ongoing support & maintenance are easier and the API will greatly simplify the inevitable platform migration.

Just remember to version your API to give you headroom for ongoing changes.

Low friction onboarding

All other things being equal, the easier it is for potential customers to try and purchase your product the more will give it a go. Think free trials and monthly payment via credit card. This opens the door to finding adjacent markets: if a potential customer can easily try your product, without having to interact with sales or their own IT department you’ll find customers you never thought of.

The wider the market for the product, the larger the growth potential and the easier it is to avoid the trap.

Feature image: Lifesize Mouse Trap by Scott Beale