Where is the value of a startup?

It’s not in the idea. Harsh, I know, but it’s true.

Ideas are everywhere. In coffee shops, boardrooms, and late-night WhatsApp chats. Some sound groundbreaking, others downright wild. But an idea, no matter how brilliant, is like an uncut diamond—potential without polish. Its value? Practically zero until you do something with it.

So, where should you put your time, energy, and investment? Let's break it down.

As we’ve already established, ideas are ten a penny. Even if you have calculated a massive TAM, SAM, and SOM, your idea is worthless.

There are billions of people in the world and probably millions of people in your industry/sector. Most ideas are not widely published, so the chances that your idea is unique are slim to none. That's okay; ideas do not need to be unique. In all honesty, most investors would prefer the reassurance that comes with competition to the risk of a mad scientist.

Ideas start to become valuable only when you have done something with them. When you think them through in detail. When you have a solution for all the challenges. This value is vaporous if the result is only in your head; it needs to be documented and accessible for the value to be extracted.

The value of a developed idea is highly variable and correlates with the quality of the thinking and the ability, experience, breadth, and diversity of the thinkers. There are lots of thinking tools that you can use to improve the quality and communication of your idea development and to ensure you explore all directions—technical, user, business, etc. Please share any of your favorites in the comments. However, you should be careful. There are simple templates wrapped in fancy snake oil branding and large communities of wannabes and the dangerously helpful, with 1001 recommendations that can distract you from making real progress.

The main issue with paper exercises is that they are theoretical. “I'd definitely pay for that” quotes do not equate to receipts. The value they hold is only potential. And to make matters worse, paper exercises and customer surveys are usually poorly executed, which—given they take time and send you in the wrong direction with false confidence—gives them negative value.

Moving beyond the theoretical is a must to build value. Rightly, implementations often start with a proof of concept that demonstrates and de-risks the core essence of the idea. Your idea may be highly technical, such that the proof of concept needs to demonstrate a technical solution, but that's not enough on its own, and many new products use only proven technology. Every proof of concept needs to convert the theoretical result into an evidenced empirical fact. It needs to demonstrate real user buy-in, literally. It needs to fit into a customer's processes, or they need to change their workflow to accommodate it. Your proof of concept should be rough and ready. It should be focused on the core value proposition and may or even should have a secret squirrel behind the scenes manually completing some actions or resolving issues. If your proof of concept is a success, then it is at this point that you should have paying customers. It works; you've put it in front of someone who needs it, and they say it works for them, so charge them. But keep them sweet; give them a discount, be responsive to their issues, and refund them if things go wrong.

This means 2 things:

1. A real implementation, replacing any vaporware with the scalable implementation. If you are to sell your startup, this is the thing you have built; this is the nugget of value. This is the thing others want to run or integrate.

2. A robust implementation, providing the on-ramps and handling the edge cases that are only tolerated by your understanding early adopters. Together these unlock your ability to scale out to as many customers as you can reach.

If you have 100K to invest, invest most of it in actually building your idea; don't burn too much on consultants, surveys, management fees, and mock-ups. Trust your gut. Research tells you about the past, not about the future. And innovation is not made of consensus.

🔗

Supporting journeys are all the cruft that surrounds the core purpose of a product. The number of startups we see who spend their first few weeks building an onboarding flow to a non-existent product is a massive bugbear of mine. At the POC (proof of concept) stage and even for some MVPs (minimal viable products), you don't prove anything by having a user set up their username and password. This is just one trivialized example of a supporting journey that consumes effort but adds no value—that is, until it does. There comes a time when these supporting journeys start to unlock the ability to scale or a secondary product line.

By the time your users are your core value, you have already succeeded and graduated into the class of startup alumni. Congratulations. Until such a time, focus on each user one at a time, their user experience, and the value the product gives them. Your users are of the utmost importance, but it's the strength of the relationship and the recommendations, not the absolute number.

Just my cynical unpopular opinion, but let's start a conversation, shall we? The value of IP is primarily for the law firms who take their cut whenever you use it. For a cash-strapped startup, are you really in a position to leverage your IP? I view IP like bitcoin. IP has value because people believe it has value. If you can find a partner law firm to help you secure IP that's a win-win for you both, then do it, providing the effort is small and not distracting you from core development. Better to have something for something than nothing for nothing.

Capital is the physical assets of the company. Growing value in capital is hard and scales linearly. You can be a capital-backed tech company if, for instance, you have the physical resource for quantum computing that others rely upon. The vast majority of tech startups should have very little in physical assets; their services are hosted by cloud providers and SAAS companies.

Some people may argue that the source code written by your developers is capital. I could buy into that. However, when you sell your startup, the new owners will not fire everyone on day one and take the source code. At thestartupfactory.tech, we try hard to write source code that is well organized, simple to understand and maintain, and that can be deployed and run with a single click. The reality in many startups is that people hold pivotal knowledge required to use, run and maintain the product; the source code alone is not enough. This problem can be exacerbated by scenarios common to startups: small stretched teams focused on launch, junior developers figuring it out as they go along, and external agencies with misaligned motivations. I am now stepping on the toes of the next section.

Your people are fundamental to your company value.

As I keep banging on about in my other articles, you can never develop and release a perfect autonomous product on the first attempt. When something goes wrong, it is your team who will debug and resolve the issue; if they have experience with the product, they will do a better, faster job, and you will have happier users. And when customers give feedback or request features, a team that knows the customers, and knows the domain, and knows the ins and outs of the product will impress the customers with their insight and respond quickly with a valued enhancement.

To build this 'people value,' you need a stable team with the right skills mix, and each player on the team needs the right motivation and aligned incentives. This is much easier to achieve with an in-house team, although far from guaranteed. In your startup's early days, when there is not enough cash for salaries, onboarding a whole in-house team is usually a stretch too far. Finding a tech partner and sharing risk in a win-win lose-lose relationship is the ideal substitute. Thestartupfactory.tech, as a partner and investor, wants your company to grow and succeed on its own; we want you to build an in-house team and build your team's experience and skills so that you can stop relying on us, but until then, we have your back.

Off-shoring and outsourcing to agencies can work, but it is tricky, primarily because they have different incentives. Who benefits from a low quote followed by under-delivery? Who benefits from lots of change requests and ongoing support contracts? Who internalizes the domain and product knowledge? And why would an agency with a steady income invest in good documentation, easy developer onboarding, and efficient processes when their client is locked into a profitable contract? Most agencies are not bad actors, but even those with good intentions are inevitably influenced by the incentive structure; they don't feel the same pressures that push for improvements. When outsourcing: Be creative with the contract terms and incentives; include additional rewards for meaningful achievements—such as delivering early with a low defect count, or 100 user journeys completed without dropouts or errors; Try to build win-win scenarios and keep the transition to in-house development open.

Some of the issues above can also apply to in-house teams. The relationship between a client manager and the client could trump that of the company. Developers can make themselves indispensable by over complicating implementations and not documenting or simplifying processes. Some people may be more motivated by being seen as the hero who saves the day or as the team's expert, such that they are happy with a process that relies on them, rather than maturing the process or team to the point they are redundant. A well designed and well implemented process is boring. If your process has surprises and heroics then it can be improved and your people, or suppliers need to be motivated to do so.

In our team we run monthly retrospectives using this app. One of the categories we score ourselves in is "Growing Capability" in which I only score the team the mid level amber when they have internalized some experience or learning, the top level green score is awarded when we can implement that learning in code so that everyone can benefit. Your people are of most value as they keep you moving forward, but you have to constantly bank that value by converting it to concrete implementation so that it is not lost when the people or situation changes.

For some people data is everything, but it is also a political hot potato. I will only skim lightly over data value, as I did when discussing “Users value”, as its direct value is often both the end goal and the by-product of work. You legally need to be transparent and careful about how you use data and that is a topic for an expert author.

That said, I think we can distinguish metrics and metadata which can give you very valuable validation that your product is or is not working, and can indicate the direction of travel or point towards solutions. But to benefit you need to capture, process and interpret lots of metadata, focusing on this can be distracting for an early startup, and requires skills and experience that rarely overlap in the venn diagram of startup salaries. Another push towards finding the right partner (are you bored with me banging that drum yet?). Metrics, when captured and understood, are valuable to you only in conjunction with your people and processes.

🔗

One last point. You can't stand still. No matter which level of value you have reached, the angels are constantly supping their share. Your competition grows and improves. Your IP expires. Your capital degrades. Your people seek greener pastures. Your software needs patching. Your users are tired of waiting for upgrades, and fashion leaves your once beautiful design at the back of the wardrobe.

You need a team or partners who are with you for the long haul, who are constantly motivated and refreshed.

Make a point of periodically reviewing and recapping the value you have, the value you could have and also the value proposition to your customers.