So you’ve had your eureka moment, having dreamt up a revelatory, subversive idea to leave your mark in the world. You realize this vision is best materialized as a mobile or web product, and in front of you, the path of decisions diverges a thousand times of what to do next.
Here’s one of the most practical guides to helping you turn your vision into a grounded course of action, leading you to tangible success. From this moment onward, prudence and diligence are the most critical traits to have and they must be maintained at all times in good faith.
Q: How do I choose my co-founders? How do I reassure myself of my co-founder’s posterity and value in this new venture?
A: Take your time and don’t rush into declaring your immediate friends and colleagues your partners in business. We get it. It is about trust and comfort, but you have an astounding idea and astounding ideas deserve well-rounded, potent co-founders.
At the end of the day, you need to unbiasedly vet a wide pool of co-founders, each candidate with deep insight and purview into their discipline, a truly proven track record and a raw drive and passion to help you materialize your vision. They also need to possess traits of enduring persistence and consistency. There should be minimal overlap in skills, and there has to be synergy across stakeholders. All of this would augment the aspect of trust and comfort.
Q: With every product, there’s always design and engineering. But what about strategy?
A: Before you jump the gun on investing all of your money to engineering your idea, you must first substantiate it in the process of research and strategy. If your hypothesis doesn’t have grounds to disrupt your industry, then the chances of your product gaining traction and growing after launch are slim to none. Always ask yourself these questions before jumping to development:
What problem am I solving? Can my solution’s revenue scale and does my solution serve a wide scope of the industry? Is my solution repetitive with what’s out there? What is the unique user experience of my product? What makes my product different, and better? Who is my target audience and what are their user preferences and behaviors? Am I really planning a MVP that will test my hypothesis in a lean, simple way? And lastly, does my vision have a reason to exist?
If you are having trouble answering these questions, then you should not be jumping into engineering and product design. Make sure that the answers to your questions are also vetted by a trusted third party.
Q: How do I know if my vision and product have a reason to exist?
A: Here’s our practical guide to answering such an elemental question with a substantiated process. We always believe that each and every idea, particularly in the tech era, needs to do one or a combination of the following:
Convert — Build a 10x better product than the current market leader and create the canonical platform to take market share, e.g. MySpace vs Facebook (constant eye thrashing of spammy content vs a streamlined way to keep in touch).
Invert — Take an existing business model where customers tolerate points of friction, and resolve those agitations by inverting the model, e.g. Blockbuster vs Netflix (per rental costs vs subscription streaming).
Subvert — Remove the middle man and the barriers of entry to equalize the playing field, e.g. Broadcast Networks vs YouTube (a webcam in lieu of millions of dollars of broadcast hardware).
You will need to unbiasedly evaluate whether your idea meets at least one of these minimum requirements.
Q: How do I choose my founding team?
A: If your idea converts, then a UX/UI disciplinarian on a minimum 5 points equity level is absolutely necessary. UX/UI predicates the value proposition and why its 10x better than what’s out there to your customer. If your idea inverts by introducing a new business model to an industry, then a CRO/CFO is critical to ensure there is solvency and a grounded financial model behind your experiment. If your idea subverts, a prodigy technical co-founder will be fundamental to creating technology that displaces the barriers of entry and the monolithic middle men.
There are of course other roles that you can consider, or you could always create a combination of these three roles. This is a general outline of which stakeholders must be incentivized on a founding team member equity basis in each circumstance.
Q: Lastly, is it ok to outsource? What about offshore?
A: Yes, outsourcing is ok and it is especially appropriate if your co-founder is not a jack-of-all-trades. Outsourcing grants you the opportunity to get mavericks across multiple disciplines working on your product, given the agency you choose stands by a strong value to price ratio. Choose partners, not vendors. Your strategic partner(s) in outsourcing must absolutely share and dwell in your vision. And your outsourced partner needs to have a deep background in building infinitely scalable tech and designing first-class products that meet user expectations.
Offshore? Absolutely not. When you offshore, you risk encountering a myriad of problems. From lack of communication to miscommunication to code quality issues. One of the most common problems you might come across is that you didn’t get what you expected and the primary functions were not as they were intended. The code was executed according to obsolete practices, and is unscalable and impossible to code on top of to add new auxiliary feature requirements. Be wary of trying to find a quick fix, because before you know it you’ll find yourself scrambling around.
With a small to nonexistent budget, you will lose sight of the most important thing to you — the clear vision that you started out with.
We work with entrepreneurs and enterprises to materialize their vision into a liquid business, solidifying a disruptive product hypothesis to undermine competitors’ market share and clear the path for them to become leaders in their industry.
You need to justify your product’s reason for existence before you start to beta test a product that doesn’t solve a problem. Don’t beta test a broken promise, because you won’t be able to fulfill it — not with spaghetti code, a poor hypothesis, and a nonsensical UX.
