In general when solving problems, I like to start out by working backwards. It works quite well when building software. Here are some questions I ask myself: How should this thing I’m making look? What should XYZ page look like? What should this class do? What methods will the users of this API need? What does the output of this algorithm look like?
I think the first place I read about this concept where it actually stuck was in Stephen Covey’s 7 Habits of Highly Effective People]. The idea is pretty simple: by envisioning the end state, you naturally add constraints to the system. Constraints simplify the process of making decisions, particularly about what the most important features are and which ones don’t matter so much.
I think this same concept applies in business (among many other aspects of life):
- What are the primary measures of your success of your business? Do you want to be the world’s biggest company by employee number? By the number of users you have paying for your product or service? By your revenue generation/MRR or your YoY growth? By Market Cap?
- What are the primary measures of success of this marketing campaign? Do we expect to increase active users by 10%?
By defining what success looks like for a particular venture, we provide ourselves with a measuring stick to gauge progress and well, what gets measured gets __.
The question “What are the primary measures of success of your business?” definitely requires some introspection and there is no right answer. But, being the opinionated person that I am, I’ll explain what comes to mind when I think about this: profitability. If i’m consistently profitable, then the business can continue to operate (see Paul Graham’s Alive or Dead).
The answer may differ across the board, and I have never owned a business, so I’m speaking only from a place of ignorance and from the thought I’ve given to this idea, based primarily on reading information from other successful business owners which I admire. Also, I’ve worked at a few startups that unfortunately haven’t managed to make it out of the womb breathing, so I guess that guides some of my perspective.
One mistake I’ve witnessed is founders not taking ownership of defining these principles (or being actively involved in the process). Instead of setting up these constraints and properly communicating it to team members, they let the team build away into oblivion without identifying what a successful v1 of their product or service looks like.
Another issue I’ve witnessed is a failure to be cut-throat about feature prioritization and what is most important to be working on. There is an infinite number of features that might one day be useful for your product: Yes need to worry about scaling to 20k users (even though current user count is 0). Of course we need to instrument our app to monitor performance (performant for who?). How can we live without a polished CI/CD pipeline?
If the end goal is unclear and furthermore not properly driven by those who are responsible for owning the vision and paving that path, even the best developers most likely won’t know what is most important and thus, will end up working on whatever they think is important (if you’re lucky) or whatever they think is cool (if you’re less lucky).
There’s so many questions to be asked when starting out your business, but a majority of them just DON’T FUCKING MATTER (at first). If you’re not profitable, and you don’t have a (relatively) clear path to profitability, none of these questions are worth answering immediately (unless you’re all aboard the infinite growth train). Here’s some questions to ask instead:
- Is the product I’m building/service that I’m providing useful?
- How are we going to acquire users?
- How can we test this hypothesis to see whether this will actually onboard users?
- How much will users pay for this service?
- What features will users actually pay for?
- How much market share does the competition have? What differentiates my product/service from the established competition? Is it a significant enough of a difference that it will pull users away from the platform they currently use? (people often avoid change) Has anyone else tried this before? What happened if so? Can we test our idea first before going all in?
The reason to ask these questions is that it gets you focused on building things that people will actually want to use. You could build the most polished UI with the latest and greatest tech stack, but I’d say ~90% of users could care less about this. Does whatever you’ve built provide value to the user? If so, they’ll probably use it (Pieter Level’s Nomad List started as a spreadsheet).
And I’m not saying that the aforementioned things I mentioned don’t matter ever - they certainly might be problems worth solving in the future. The point is, those questions are only worth asking if your product survives long enough to where those problems actually become relevant. I think we should problem solve the issues we face “on-demand”, rather than imagine problems we might have in the future (or those which others are facing). Instead, focus on building something that customers want and that has a clear path to being profitable. Once you hit that stage, you’ve freed yourself from the burden of company death (my wife calls those that don’t make it “guagua muerta”; morbid and gruesome yet reasonably accurate name). If you just want to go raise money and blow it on talent, thats fine, but just clearly define how your path to success looks before doing so. My ignorant perspective sees the money raising route as counter-productive, giving external decision makers power to decide what is right or wrong for your business. It’s definitely the path I would like to avoid.
The point is, if you define your initial goal as profitability and work backwards from there, your decision making framework will emphasize hypothesis testing (in a short time frame) things that might actually generate money for your business and discard the rest until that initial milestone is met.