People often contact dev shops with startup ideas. Many dev shops are guilty of encouraging this by advertising that they will take your idea from dream to reality. As you describe your vision in discovery meetings, you might buy into the hype that a dev shop can lead you through ideation to launch and that you can relay reqs to them as you watch your product transform from an idea to an app.
It just doesn’t work that way. Dev shops aren’t in the ideation business. They’re not in the business of creating businesses. They can excel in custom software development which is an important part of a tech startup, but it’s not the only thing.
In his well-known book Inspired, Marty Cagan preaches that the merit of your product idea depends on four major principles: value, usability, feasibility, and business viability.
He refers to these four areas as product risks. Even more emphatically, he calls them the four big risks. So make no mistake about it: in his view, the potential of your product (and therefore your startup) starts and possibly dies based on these risks.
You can also tweak the terms to desirability, usability, feasibility and viability.
*https://www.thefountaininstitute.com/blog/getting-started-in-testing-and-experimentation-a-designers-guide
If you’re going to the dev shop with an idea that hasn’t been vetted for value and business viability, you’re wasting your time and money. If you don’t own usability testing, you’re making a big mistake and missing out on a precious opportunity.
Aspiring first-time founders, particularly non-technical folks, often assume that once they have a startup idea, the next step is to build the product, but it’s just not true. You can and should go a long way toward exploring value and business viability well before investing in tech. Once you have validation that you’re solving a problem that you can make a business out of, a well-run dev shop should shine in tackling the feasibility risk.
They should have the technical expertise to walk through the problem that you’re solving and evaluate your ideas for infrastructure, complexity, and cost. They should be able to orient you around stacks, technical debt, and engineering resources. Most importantly, they should be able to tell you whether your idea can scale with existing tech and how much needs to be created from the ground up as a custom solution. A dev shop should be able to do all of these things.
It’s important to get this engineering feedback early on because it will inform what’s possible in your product vision. A limitation in technical feasibility might inspire a modified version of your product idea that solves a monetization problem. A useful API might enable you to fast track development and build out a feature that had seemed complex. The four risks influence each other, which is why Cagan’s philosophy involves bringing together the product manager, product designer, and lead engineer early on as they take ownership over exploring the risks and determine if there is a path forward. He insists for a focus on business outcomes rather than output. He warns against premature roadmapping and just sending specs downstream to engineering.
Some people argue that a dev shop can’t match what a strong internal product team can do in terms of velocity, pivoting, and collaboration. But a good dev shop has a range and depth of knowledge that one or two senior developers on an internal startup team just won’t have. Software architects, senior developers, product managers, DevOps engineers, and UX/UI designers who collectively can give you a full picture of the size and scope of what your idea involves. A startup should be gritty and lean and agile, but getting technical guidance early on can prevent nightmarish situations of prematurely over-engineering, needlessly reinventing the wheel, or fall down the slippery slope of feature creep.
However, if you engage a dev shop with vague product ideas and untested hypotheses around value or business viability, you’re setting yourself up for failure. Dev shops that claim to turn your idea into reality are overselling their capabilities and grossly oversimplifying what it takes to have a product vision and iterate to product market fit. As a founder, you need to know your target audience and their pain points better than anyone else. That’s why setting out to solve a problem that you actually have is so powerful. No dev shop is going to have the customer understanding or domain knowledge that you must have.
As a founder, you need to determine value and business viability. A dev shop can lead the feasibility assessment. What about the usability risk? Doesn’t usability fall within tech too?
The question of usability is more nuanced in terms of ownership. Most dev shops do UX/UI and should be able to design a sleek, user-friendly interface. But early on when you’re weighing product risks, testing usability doesn’t require technical skills; it requires soft skills. Just as you need to learn from customers about how valuable your solution is, you need to study how customers interact with your product. Is it easy to use, intuitive, and frictionless? Cagan discusses at length the dos and don’ts of running user tests in Inspired. You need to be observant, objective, and detached. Don’t lead the user down any particular path. Rather than demoing the product, you want to sit back and watch what the user does.
Usability is closely related to value and feasibility. If a product takes too much effort, time, or attention to use, people will lose patience and not see the value. If the product is well-designed but lacks functionality, people have no reason to try it out. The product needs to be designed simultaneously as it is built. Form and function go hand in hand. As the expert on your target users, you will know better than anyone else what interface and design works for them in order to access the value that your product provides. Leverage the UX/UI experience and best practices of the dev shop, but be hands-on and run user tests yourself.
Follow the model around Cagan's four big risks. Keep in mind what you need to do. Understand what a dev shop can and can't.
