One of the first principles taught in high school geometry is that the shortest distance from Point A to Point B is a straight line. And while that principle is easy to grasp, it requires knowing two key pieces of information: Point A and Point B.
Clients who approach us typically have a strong vision of where they want to go, Point B in our analogy. They’ve done market research and often even raised money on the premise of getting to Point B.
However, for clients who are immersed in the day-to-day work of running a start-up or an established small business, it can be difficult to find the perspective needed to see where you are starting from or exactly where you are on that path from A to B.
Who realistically has time to take a step back and meditate on the where you really are when you’re busy keeping tabs on staffing, inventory, product development, new initiatives, Slack channels, never-ending emails, and the inevitable late-breaking emergency?
We love to talk with people who have a strong idea of where they want to go, and we love helping them figure out how to get there. But sometimes our first step in helping might look like challenging a client’s assumptions. We want you to be successful, which requires adapting to change over sticking to a plan.
Success is a journey, not a destination.
Arthur Ashe
Think of us as your personal trail guide on this journey from Point A to point B, but before we head out, we need to ask some questions to make sure you’re all packed up and ready to go.
Does your product solve the real problem?
Some of my favorite meetings are when we talk clients out of custom software. A client brings us in to help them build software, and as we talk through the system they envision and we dig into the real-world business problems being solved, the people affected, etc., we eventually realize this is not a software problem. It’s often a communication problem or maybe a process problem.
Software might help down the road, but until the business units can figure out how to work together, codifying dysfunction into software isn’t going to help much. This fundamental reframing of the problem changes their notion of where they are.
Will anyone buy your product?
Another flavor of this is when we get brought into create an MVP but during the course of the project, the client realizes they didn’t actually know their customers well enough to understand purchasing behavior. Now they need to start over. Understanding your customer’s pain points is essential, but it’s not enough. You need to know if they will actually spend money on your product. In some markets, the pain is real and budgets are available, but there is too much institutional inertia to switch to your product.
That’s why we love being involved as early as possible. Our discovery process helps avoid this fate by performing user testing, figuring what hypotheses can be tested before building software, and validating product market fit in general.
Are you where you think you are?
One of the sadder, more frustrating experiences is when a client brings us in to help “finish up” an MVP that’s supposedly 80% done. But as we get started, we realize that 80% is more like 50% or maybe even closer to 0% if the product is full of security and architecture problems.
These situations can result in extremely tough scenarios where a startup doesn’t have enough money to start over but risks existential brand damage moving forward. We can usually find a way to patch up a bad codebase to get it limp across the finish line, but it’s not always possible to do so in a responsible way.
This is why we put a lot of effort into educating product owners about the costs to operate, market, and maintain custom software. Even if you work with a good firm who manages to build a solid initial product on budget, you need to have an operating budget to last until revenue comes. This can take much longer than expected, and software can be much more expensive to maintain and operate than expected. Custom software is never done and instead requires frequent updates to apply security patches and meet changing requirements with hosting platforms, among other considerations.
Getting from Here to There
At Simple Thread, we don’t want to just take your technology budget and turn out a product that will meet a short term need, or worse, literally codify a problem into your systems. So we take the time to ask questions and talk to team members and clients to get the context of your product idea or system solution.
Having a clearer, deeper understanding of where you actually are can change where you want to go and how you want to get there.
We want to get you where you want to go, but we can’t do that with a generic plan. We’re going to make sure we know where you are to start with and plan your route according to your company’s needs, assets, and goals. Then we’ll walk the path alongside you, revising and evaluating along the way, to make sure your journey ends where you need it to.
I may not have gone where I intended to go,
but I think I have ended up where I needed to be.Douglas Adams
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
