Quite often, clients will come to me and ask me for help doing any of a number of things. Redesigning and rebuilding their website. Building a single-page React app. Creating a WordPress or Shopify theme. Building a mobile app. Or otherwise creating or altering a complicated piece of technology.
I could stop right there and hit them with a price tag immediately, collect half up front and start coding. I don’t. The next thing I do is ask them a question that just might prevent me from getting that money.
What’s the intended outcome?
Why do they want this app/theme/site/redesign/widget done – what’s the goal? Almost always, they’re looking for things like more traffic, more sales leads, higher revenue and so on.
Then I go ahead and ask my second question, which is almost guaranteed to prevent me from getting the project 50% of the time:
“How do you know that this project will help you achieve that goal?”
E.g., “How do you know that building a mobile app will bring you more customers?”
Or, “How do you know that redesigning this website will increase revenue?”
If the answer is some version of “why wouldn’t it?”, I have them stop right there. They’ve gotten ready to put down a lot of money on a guess; they’re guessing that A will cause B without any sort of testing.
Validate your assumptions
It’s common mistake for people to think that a website redesign or custom-branded app will magically increase their revenue, get them more website traffic or increase leads. And quite often, developers and designers take their money and move onto the next project. Because technically, it’s not their job to tell clients how to spend their money. Clients are the businesspeople – they make business decisions. Designers and developers design and develop. Everyone’s just doing their job, which is ok…but it’s always preferred if the end result satisfies the client’s end goal.
In the world of all things agile and lean—software, UX, product development—it’s crucial that every idea you have be treated as a hypothesis. A hypothesis is an educated guess; and with some validation or testing, it can be a much smarter educated guess. A hypothesis needs to be tested before it becomes a fact. Without some data, be very careful where you put your money.
As a technical strategy consultant (who happens to code, and sometimes oversee designers and developers), I don’t take the money and run (anymore). I get a lot more joy from having my clients make money from the work I do since I want them coming back to me with more of that money I helped them make. It’s like the old Vidal Sassoon commercials for those old enough to remember: “If you don’t look good, we don’t look good.” If I help you make money, I look a lot better.
Think before you leap
There is a multitude of low-cost ways to start testing assumptions like these before you redesign, build, or engineer anything. Everything from landing pages to low-fi usability tests to “coming soon” product websites and so on. The different methods could fill an entire blog post.
But if you take anything away from this one article, take away one thing: before you spend money on a software project of any kind…what do you hope to gain from it? And what evidence do you have that you will?
After you’ve thought about that a bit, drop me a line.