Why we won’t work on your project

When people think of custom software development — especially when hiring a third-party developer to perform said development — they generally think in terms of projects. It’s an entrenched way of thinking, and it’s not totally without merit. Many companies, when they’re conceptualizing a new application they wanted developed on their behalf, start the dev. process by putting together a requirements document. Then, after some deliberation, refining and tweaking, the requirements document will go out to prospective bidders on the project. Once the bids come back, the choice then most often comes down to some combination of 1) how long will it take to deliver, 2) how much will it cost to get there, and 3) can these jokers actually deliver on that which they promise?

This is a perfectly valid engagement model. For simple projects or supremely detailed and specific ones (as in the requesting company has thought through everything and has an exceedingly specific vision for the project), handing over a requirements doc and having potential partners compete on delivery dates and price makes good sense. However, it’s a lower form of partnership; it’s more of a boss/employee type of working relationship, as opposed to a partnership built on collaboration and additive input.

That’s more of what the best companies have to offer.

The difference can be understood as the variance between a product and a project mindset. A project mindset is what I’ve already outlined: a client has a very specific set of features and requirements they want met, put it down on paper, and expect a deliverable by the date and time you quote for the amount you quoted. A product is something different; it’s a mindset we’re always trying to bring to the table.

When your development partner is thinking in terms of a product delivery, it changes the entire relationship. Instead of simply developing a specific feature-set you request, they’re trying to offer value, creativity and insight at every turn. It keeps a development partner focused on business objectives, audience, end goals and measures for success instead of simply hitting delivery markers. Your developer can take a wide-angled view of what you both are building together and offer advice and insight into how you can best achieve it together. It forces/allows a development partner to focus on the long game. Instead of hustling to bang out version 1 and then rid themselves of your project, they’re thinking of the best product roadmap: what’s the minimum viable product that can start attracting an audience? What’s the next wave of features our customers are going to demand? How can we leverage consumer feedback into version 3? What support structures do we need to build in order to service this app long term?

Instead of cramming as many features into version 1 of a project to goose the cost of the engagement, product management shops are thinking about the best roll out strategy for your business, not just for this one app (or feature set within an app). Product shops are trying to bring perspective and insight to the development process for years down the road. They’re focused on how to build a sustainable business, together, not just how can they deliver what features the client asked for.

At ENO8, we color ourselves product folks. We have expertise, enthusiasm and creativity we can bring to bear on any of our projects, and we think the best results always come from client and developer working together to solve a business problem instead of one simply taking orders from the other and spitting back a carbon copy software solution. If you look for that feature in your next software partner, we think you’ll really find a competitive edge to leverage.

Happy hunting in the search for a better product partner!