Anatomy of a Discovery Phase
“How much would it cost to make this [app/website/product/widget]?”
It’s a question I get asked a lot, both in personal and professional settings—a perfectly reasonable one.
Unfortunately, there’s no magic formula or cheat sheet I can give you. There aren’t any one-size-fits-all solutions—at least none that I would recommend. In order to give you an accurate answer, I need to know a lot more about your concept, your constraints, your requirements, and your wildest dreams for the product.
At Mobelux, we call this a Discovery Phase, and I see it as the natural first step in bringing any idea into the world.
So when you ask that question, you’re probably not going to love my initial answer, which is usually “I don’t know,” followed by a long-winded analogy about cars (more on that in a bit). But first, let’s take a trip down Memory Lane…
Ages ago, I worked in various retail positions for a well-known computer company. Culturally, it couldn’t have been further from the stereotypical “sales” job, and, contrary to most of our customers’ assumptions, we didn’t work on commission. We were encouraged to spend as much time with our visitors as possible, whether they intended to buy something or not.
As a result, I got to know people. I got to talk to them about how they wanted to use the computer. I got to help them make slideshows and burn their home movies to DVD. I exposed them to new worlds made available to them through technology.
I sold a lot of computers in my day, but never felt pressured from my higher-ups to sell something to someone that wasn’t exactly what they needed or wanted. At the center of this sales approach is a philosophy that shaped my approach to software design and client services: It’s OK to say “I don’t know” as long as it’s always followed by “let’s find out.”
What I love about “let’s find out” is that there’s an implied sense of collaboration, problem solving, curiosity, and empathy. It’s also a good exercise in humility. I never had to feel bad about getting stumped. I never had to make something up to sound more like an expert. All I needed was the confidence that I wasn’t alone—that I could use all the resources at my disposal to arrive at not only an answer, but the best answer, together.
It’s a great lesson to teach a twenty-something know-it-all (like I was), but it’s an even better one to apply to any collaborative work environment. Because if you lose that curiosity, close yourself off from your clients and teammates, or start trying to find problems that fit a solution rather than the other way around, you’ve set yourself up for frustration, conflict, and even failure.
Back to that car analogy I mentioned.
It works because software can be a costly investment. A lot like buying a car. You can get an affordable car just like you can get an affordable app. You can show off with your limited-edition Ferrari, but you’re going to pay for that privilege.
So, you come to me, your friendly neighborhood car salesman, and say, “Hey, I need a car. Which one should I get, and how much is it going to cost?” I think anyone can see how that’s a difficult question to answer. I don’t know anything about your constraints (budget), your requirements (the four kids and a dog you need to transport), or your goals (0–60 in under 5s). Without that foundation, I can only give you a comically unhelpful range, like “probably somewhere between $10,000 and $100,000, but maybe a lot more.”
So, like any good car salesman, I start asking questions to figure out what kind of car you need in order to provide a more accurate cost estimate. I’m not going to pick a car off the lot and convince you that it’s perfect for you. I’d rather not sell you a car than sell you the wrong one.
The quickest way to start narrowing things down: “Do you already have a budget?”
It’s OK if the answer is “No”. Maybe you don’t know yet. Maybe money is no object. Either way, that’s still information we can use. I know it seems aggressive to ask about budget right away. I just need to figure out if you are looking for a Civic or a Ferrari.
All those kids…do you need a third row? OK. You don’t see yourself driving a minivan? Got it. Your favorite color is yellow? Cool. As I learn more, I’m building a mental model of your ideal car. Then I’ll try to match that as closely as possible to something on my lot. It’ll be a lot quicker now that I know you’re looking for a yellow SUV with a third row for under $40K.
And that’s where the analogy falls apart — but, in this case, the failure of the analogy is almost as helpful as the similarities. The difference is, in our business, pretty much anything is possible. We’re not constrained by inventory or manufactured solutions. Instead, our constraints are usually just time and resources.
So how do we avoid the trap of jumping right into a solution before knowing the problems you’re trying to solve?
Well, first I need to understand those problems. Only then, with a common goal and mutual understanding, can we get to work on answering any of your questions with conviction.
At Mobelux, we do this Discovery Phase for every project. It’s more than just research. And it’s not just about coming up with better cost estimates. It’s about coming up with a better product.
Every product is made up of the answers to hundreds, even thousands, of questions: How can this product succeed in the market? Who is going to use this product? How much will it cost to make and maintain? What’s the right font to use? Does this color have any negative associations in other cultures? What technology stack should we use? Does this interface make sense to our users? You get the idea.
Once we know (or think we know) the answers to some of these questions, we also need to understand our constraints. What about your expectations for the product? The expectations of your users? Does this product need to fit in with an existing ecosystem of related products?
All of these answers form our basic assumptions about the potential solution. Each assumption needs to be tested, validated, and revised. We learn from every failure and celebrate every success, improving our solution with every iteration.
The process of validating and testing these assumptions results in a variety of artifacts and deliverables — scope documents, user interviews, wireframes, prototypes, or brand guidelines — all of which aim to push our solution further, closer to our end goals.
This is our discovery process. This is how we make products — and make them better. Through collaboration and teamwork we attempt to answer these questions, challenge our preconceived notions and assumptions, and empower everyone involved with the simple notion that it’s OK if you don’t know the answer.
Because together we can solve anything.
