Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0Share on Reddit0Email this to someone

As developers, we love to code, build, create, invent. As consultants our livelihood is dependent on this; yet, I believe we have a certain responsibility to decline jobs when they’re not warranted (See: The Importance of Saying NO).

Far too often in the past I’ve seen tech built when tech doesn’t need to be built. Startups that want to build a “platform” before they’ve got a business model. SMBs that think by just having a website their internet presence will grow. Brands that think having a cool, branded app with the latest hi-tech whatever will increase sales and recognition.

The truth is, most of the time these ideas are unfortunately baseless. A complex platform will only work if you’ve validated the model (and even then, there are tons of risks). A website without promotion will never be seen. An app will only increase sales if it can connect with buyers with the product in a way they weren’t already connecting.

Without some kind of validation, all of these things are just ideas. Beautiful, expensive, risky, probably wasteful ideas.

What’s the real goal?

Most of the time these ideas are motivated by genuine goals every business has. More customers, more sales per customer, more name recognition and so on. Whatever tech thing (website, app, etc) they want to build is an attempt to further one or more valid business goals. The easy trap to fall into is considering it a guarantee (or likelihood) without any kind of evidence.

Sure, and app with a giant dancing chicken on it might drive more customers to my car dealership. I’d better have some real data to back that assumption before I go dropping tens of thousands of bucks on design and development costs.

The key piece of advice I give to clients in these cases is to accept that you’re making assumptions, and try to change that habit. Treat these things as hypothesis instead of guarantees, and you’ll be a lot less likely to drop tons of money on something that doesn’t advance your business.

This is challenging for consulting teams since it seems to violate our own business model. We get paid to build things! (I do a lot more than that, including developer training and product stuff, but that’s besides the point.) In reality this is far from the truth.

Long-term credibility over short-term cash

The truth is, we gain a lot more from steering the client in a direction that is better for them than we do from just taking their money and building them anything their heart desires.

In any business, you want your customers to feel like they’re gaining more than they’re spending. If you can save someone a ton of money without them spending anything, they’ll love you for it and come back. It’s the same reason we give away free content on websites; it prevents them from ever feeling like they’re being suckered.

It’s no different with doing development work for hire. By all means pay the bills, but aim to land projects that leave both client and developer happy with the result.

How do I find out what the client really needs?

I always ask detailed questions about their business to get a sense of where their real bottlenecks are. Sometimes a client will think they need to get more traffic, when they’ve already got a bunch that they just need to make use of better.

I ask about their business model. If their approach sounds like “we’ll make money once we build this,” I ask them how they know. If they’ve done a lot of customer research (and done it really well), then maybe they’re onto something. If they haven’t done any, the only thing they should be building is an MVP – which generally shouldn’t be an app, it should as simple as some landing pages, surveys or other low-investment validation.

For existing businesses, I ask about their metrics. If they don’t have any, that’s a red flag. If on the other hand, they know they’ve got high acquisition numbers and low retention numbers, then building features for them to increase retention may not be such a bad idea. Otherwise, collecting numbers for each of the AARRR stages should be their first step.

Shut up and code? Not really.

There are definitely projects that are already in motion and hire freelance developers as an extra set of hands. Or they’re clear on their product direction, and are hiring us solely for our technical chops. In that case the job is clean cut – get’er done as fast and effectively as possible.

In other cases – such as where the client isn’t natively technical, or they’re looking us to head up the project – we owe it to them to keep their best interests at heart. Anytime we can point them in a direction that is more focused on actual returns for them, we’re building our reputation by giving them actual results – rather than trading money for labor.

What are your thoughts on this? Leave a reply.

Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0Share on Reddit0Email this to someone