if (business strategy != subject) { echo failure; }

The blogosphere is replete with references to an interesting post by Michael Mace, “Mobile Applications, RIP“. Michael believes that the age of custom mobile application stacks is dead. Instead, he posits, the mobile web is surging in importance, despite its being inelegant and inferior technologically. He points out that

“A platform that is technically flawed but has a good business model will always beat a platform that is elegant but has a poor business model.”

In principle, I agree with him, but his choice of language and approach to the issue suggest that technology comes first. As he says “A platform (subject) … has a … business model (object).” I don’t mean to sound like a third-grade English teacher, but this is an important distinction. Platforms don’t have business models (or at least they shouldn’t). Business models have platforms.

For the past 14 years I have been managing teams of very capable engineers. I myself do a lot of the software design, and for some projects, the coding. It is very easy to think technology first, because that is often the way things are built. Engineers naturally want to make their software elegant.

But elegant architectures do not necessarily make money. And there is real danger that by starting to plan or build the technology before nailing down the business issues, you’ll build the wrong thing. Of course, given today’s frantic and competitive technology markets, the technology and the strategy usually evolve concurrently. The problem is that the during such concurrent development, the technology is often the most concrete thing you have. It is easy to relegate the business strategy and consumer needs to a secondary role.

The “technology first” attitude is at the heart of more startup failures than I could ever list. Never let the engineers (the crazy people) run the startup (the asylum).

But what can we do to minimize the risk that the technology takes on a greater importance than the business objectives? Here are some suggestions:

• Start every technology meeting with a review of the current business objectives. This will help remind your team of where they’re really trying to head.
• Challenge your team to explain why their technology decisions are the best choice to achieve your business goals. Never let them build the technology “right” unless they can persuasively articulate how that plays into your business needs.
• Use business milestones to motivate your technology team rather than development milestones. Don’t reward them for the release of version 2, but rather for acquiring 3,000 new users on version 2. That will make them think more like a consumer when they’re developing, and will force them to work with marketing to get the job done rather than just passing it off and saying “good luck.”
• Stress the importance of maintainability and flexibility in their software design. They will be tempted to go for scalability and stability instead. Remind them that until we have settled on what we need to build, work on scalability and stability is wasted. Maintainable, flexible code can evolve as we determine our business needs. Once that is set, we can focus on locking down performance.
• Contextual design interviews are key. It’s very easy for engineers to lose track of what customers actually need/want unless they actually see it. It still amazes me sometimes how stupid users can be (like I can be sometimes when using a new product I’m not really paying attention to). Accommodating their (our) ignorance is critical for a good product.

[Fellow engineers, fear not. Some day I'll write a post about the ignorance of non-engineer managers ignoring the technology realities, and pushing out a product that is not ready, and will never be any good.]

Readers, do you have any other suggestions about how to ensure business objectives remain paramount?