Building software isn’t easy, neither in concept nor in execution. It’s difficult. In fact, developing software is often referred to as Theory Building (Programming as Theory Building, Peter Naur, 1985). I’ll save you the trouble of reading the paper, the basic principle is that a software platform isn’t the source code, but rather the mental construct of the people that worked on it. The paper takes that concept to dive into why developer churn is a bad thing, but I really think it’s a unique take on how we as technologists have to think about solutions we’re trying to apply to the problems we observe.
Software is a Theory
What does that even mean? The root of any successful software application is that it’s trying to solve a problem. Facebook solved a problem of social connection with friends and family. Stripe solved a problem of facilitating online payments. Mailchimp solved a problem of sending mass emails.
Thing is, there’s a lot of different ways to tackle that problem. Each one of the companies above have experienced competition, and have or will lose their seat as the king solution to that problem. That’s because those solutions are just theories of how to solve the underlying problem.
When you think about startups, we often conjure up images of a group of people standing in front of a whiteboard drawing circles and lines talking through how to solve a particular problem (not that far from reality, actually…). All of those circle and lines represent a theory about the best way to tackle a given problem. When we write software, the source code of the application is simply the digital embodiment of that theory.
So the theory is still there, we’re trying to solve a problem. We’re also trying to create value and capture some of that value in the form of revenue.
From Theory to Strategy
Now that a theory is created, we have to move on to strategy. It’s not enough to have a theory. In reality, the theory stage is just an observation, which isn’t something you can execute on. We’ve found a problem and an angle on how to fix it, but we’ve got to figure out how to capitalize on that theory/observation.
We Don’t Sell Saddles
In 2013, one of the most influential internal memos was sent around to a group of people building an application that would eventually become Slack. Entitled We Don’t Sell Saddles Here, it covers a pretty important concept to anyone trying to build a SaaS product (or any product for that matter). The important lesson is that you’re not trying to sell software, you’re selling the outcome of using that product.
The example used in the letter is that of a saddle maker. A successful saddle maker isn’t one that just sells a quality saddle, it’s one that sells the equestrian lifestyle. You’re selling the innovation, not the product. You’re successful because you’re creating and expanding the market for your product, instead of just trying to find someone who already wants a saddle.
In my opinion, the industry best at this is healthcare. If you look at the imagery and marketing materials used by healthcare companies, what do you see? Families smiling together, and older person on a hike — anything and everything except an image of the service they provide. You’ll be hard pressed to find an image of a patient in a hospital bed. Why? Because they’re selling the outcome of their services, good health.
We Don’t Sell Software
I’m privileged to have been a part of building an entire software platform from the ground up. There are a couple of key problems we had to solve (and are still in the process of solving) in order for our platform to be successful. To help paint the picture, our product is a debt management platform for commercial real estate borrowers.
Sexy, I know.
While the software didn’t become public until 2019, we started down this path in 2017. We talked with CRE borrowers about their debt portfolios and whether they had any struggle keeping up with anything. Well sure, we have the same problems as anyone else, but we have a process for keeping on top of it all. Well except for… After a lot of the conversations, we realized there was a gap in the technology space for helping borrowers manage their debt portfolios.
One of the first struggles we had to overcome was defining what debt management is. It’s something every CRE operator has to contend with, but it’s not a well defined practice like Asset Management. The first step in solving the problem is defining and helping to create standard practices for debt management.
The next obstacle to overcome, is to set yourself up as the optimal solution provider for that market. This often comes in the form of demonstrating how our technology provides better results and a better experience to cobbling something together with generic solutions.
How to Create Value
If you’re new to developing products, there are about a million frameworks out there for creating a product strategy. I can’t recommend any of them. Not because they’re bad, but because they’re not one size fits all. A framework is just a way to think about and approach a problem, it can’t replace the hard work of actually thinking about how you’re going to create value. There’s a couple of things you will need to work through to get that value.
- What is the outcome you’re trying to provide? Forget the product, move back to the theory of the solution. Think about who benefits from this and why. In our case, one outcome is simply “avoiding surprises”. This usually starts out as a list of specific outcomes, from which emerge a theme.
- With the outcome in mind, develop a way to understand the benefits this outcome can provide. If you’re going to create value, your outcome can’t simply be flash. One benefit of avoiding surprises in a CRE transaction is that it can prevent a deal from blowing up (I’ve been told acquisition teams don’t like it when deals blow up…)
After you run through this exercise, you’re going to be left with a list of outcomes and the benefits this gives your users. From this list you want to start ranking the outcomes you can provide based on the difficulty on providing that outcome.
You should be able to intuitively rank this list — remember that software is just the embodiment of a theory, so the more complex the theory (outcome), the more complex the embodiment.
Why We Don’t Rank By Benefit
It’s tempting to look at these and try to do the highest benefit outcomes first. These are going to almost always be the hardest to pull off (that’s why there’s so much benefit to doing them), and more than likely depend on some other outcome being completed first.
Execution
So at this point all we have is a strategy — but we haven’t done anything yet. Ultimately, what we’re trying to drill down to is a concrete feature that we can build. Thankfully, once we’ve done this exercise, it becomes much simpler to decide on the features that should be built and the order in which to do them in.
Above we outlined that an outcome we wanted to provide was “Avoiding Surprises”. One way we can avoid a surprise is knowing what our loan prepayment is at all times, which means that we had to build out a set of prepayment features to meet the desired outcome.
Evaluating Success
Was your strategy a success? The only real way to know that is whether your (potential) customers respond to what you built and find enough value in your product to pay for it.
This is an overly simplified explanation of how we have worked through strategy. There’s a lot more to consider, like Product Adoption Curves, the Whole Product Model, and many more concepts that just can’t be covered in a single post. If you’re interested in learning more about developing products, I would start with Crossing the Chasm by Geoffery Moore (not an affiliate link, I just like the book).
For my fellow technologists out there, do you have a specific way that you work in the problem of creating value? For the CRE pros, how do you evaluate it when you look at different PropTech products?
If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.
