I’ve noticed something quite subtle in my many years of advising clients and listening to business-oriented people describe their technology’s build process. Being both an entrepreneur and a technologist, you tend to take for granted some very important insights that business focus gives you on the technology itself. Learning how to build technology teaches you to optimize to the best of technological needs. You learn to build for the best possible sophisticated technology outcome. However, where business meets technology, you no longer have this goal. And that is the nuance. Where business meets technology, technology can no longer be build strictly for the sake of the most perfect technological efficiency. Where business meets technology all technological decisions have to be made with a direct association to the business needs – or expense will begin to accumulate in between the cracks of the two disciplines.
Optimizing an algorithm might sound like a wise thing for you to do for your business, but this decision cannot be made without the consideration of the business side and weighing profit vs cost of such an endeavor. Making a task 2 second vs 1 seconds fast could seem like a good thing on the surface, but if there is absolutely no benefit to the business to do so, you are not showing your greatest business savvy.
Take for example a simple idea of a website search and compare two different business models. For the first example we’ll take the company Google. For the second, we’ll take a hypothetical law firm’s site search. For Google, making search lightning fast, optimizing auto correct techniques, even knowing what you’re actually searching for based on your previous history is tied absolutely to its business model. In order to optimize on all these points, Google devotes key development efforts, because, without these points of contention being optimized, they will no longer be known as best in the business. Now, how do you think our hypothetical Law Firm should approach the same problem of search on their site? Their clients are searching very one-dimensional type of information: legal documents. Do you need to dearly optimize for speed, making your company into a search-engine optimizing machine? Your clients will most likely not use the search too often either. Definitely not as much as google. Putting the same amount of effort into optimizing search in a small law firm is not business-worthy.
But, I don’t want you to think that business decisions with respect to technology only need to be made high-level. Let’s take something a bit more specific as an example. Say you’re a start-up and in your preliminary scope (call it your MVP) you make a few decisions of the way you want your site to be designed. As one example, you choose to have the coolest nav bar with menus that swing out smoothly as you click on them and site design that wow’s anyone that looks at it. Because you don’t talk to a developer before you work with your designer to design your site, you have no way of knowing how complicated the design is to implement using code. You take your design and you hand it over to your developer who gives you an estimate and toils to implement your design. They toil and toil over the new design and you don’t understand what’s taking so long. Your friend Johnny’s site was just as many pages; is your developer using you for all you’re worth?
What’s the problem with this structure? Where does the influx of expense accumulate? It accumulates in the crevices between the different disciplines. The more the three disciplines – business, design, development – are separated within your process of software development, the more expense accumulates between the cracks. Think how different your project would have been if you involved your developer and your designer together in the planning of the design. Think how much feedback your developer would be able to give you when you try to determine how much more expensive one design element vs another would be.
Having a programmer develop your project does not free you from being a huge part of the build process. The product needs your business acumen as you are the one experienced in the market, the problem your solution is solving, the one who has the best decision making ability for the choices to be made in the technology that needs to be guided by business goals.
This insight might start to sound to you like a good idea, but what do you do with it? For starters, you need to determine the type of developer you are working with. If it is someone that is also an entrepreneur or has worked with many start-ups and understands the differing needs of business and technology, you are in good hands, but you still need to make sure they understand the dichotomy of business vs tech needs. Before they start working on your technology, make sure they understand that they need to make make all technological decisions with respect to your business.
Work hand in hand with you developer as you develop the logic and algorithms involved in the core construction of your business. Take lead to understand the cost benefit analysis of each design and algorithm decision.
Many times, however, you are dealing with agencies or developers with little experience in business or ones that are simply disconnected from the business side. This will most definitely be the case if you are outsourcing your technology’s build oversees. And this disconnect is EXACTLY the primary reason why many start-ups fall into the pit-of-outsource-hell experience. Because of the enormous added setback of the language barrier and land barrier, such teams tend to follow (less than semi-rigorously) the list of build items you provide them. How long will they take to complete the list? Well, they’re the one’s that are giving you the estimate, so, would you also want them to make decisions on the things to optimize and the things that need to be build? How will you ever know if they’re decisions are key if you don’t know technology. When dealing with any teams that just need to be separated from the business model, make sure you have a person on your team that is technical and knows closely the development needs of your business, the development efforts that will be involved. Do not create the list without a technical partner to help you with the decisions. If, being non-technical, you simply give a list to your outsourced team, it will be the blind leading the blind. What do they know about your business model? What do you know about their blind technology decisions?
My main point to take away is, if you’re building a software – web app, mobile app, desktop app, api – that will be the core of your business, it is unwise to think the creation of this technology is purely a technological one and can be separated, or outsourced completely, without the involvement of the business side. Most of your decisions concerning your technology will be business decisions implemented with the help of technology. Understanding this will help you understand the involvement you need to have in the build of the backbone of your tech business.
