The Devil is the Details:Strategic Thinking as a COO

Before my co-founder and I decided to make Incipia our full-time operation, I was working as software developer. At that time I spent almost all of my working hours writing, talking about, or thinking about code (and if we’re being honest, I spent a ton of my time outside of the office working on my own projects).

This is because I was – and still am – very passionate about programming.

That said, my passion for programming and prejudice for “thinking in” or “problem solving in the code” blinded me from thinking strategically as Incipia's COO.

Nevertheless, over time I’ve been able to learn when I should see things through the lens of a passionate engineer, and when it's smarter to look at things more objectively in terms of deadlines, realistic expectations, and what's best for our customers.

Below, I share two scenarios that highlight the (ultimately productive) tension between my engineer’s need for technical precision my COO’s role as strategic problem solver.

Where Technical Prejudice Helps COO & Client Strategy

Prospective clients usually care about two things: launch date and budget. And almost always, they are in conflict with one another. This makes sense — business stakeholders looking for app development want to spend the least amount possible and they want a developed product ASAP. As an app development studio, the important part is the ability to generate an accurate estimate on time and money, which makes it crucial to understand the details of a scope.

The Engineer in me is always ready to get started, i.e., jump straight into our Agile planning and get to the programming.

And yet, the COO within has learned to channel that energy into a deep exploration pre-build. He has convinced the engineer that the more time we spend upfront, the better and faster the code will eventually be.

So this is where details can really help; they can support an educated estimation — something that's required to start a conversation about moving forward with a project. Moreover, they can reveal areas in which a prospective client may be willing to reduce the scope of their project, because often times there are alternative solutions that will honor a client's overall vision but merit less time than what was initially anticipated.

Case Study #1: In-App Messaging Enhanced by Technical/Strategic Tension

One client we worked with thought they needed in-app messaging – a common feature in apps of all verticals.

While it would have been possible to build, i.e., perfectly in-line with the speed and budget needs of both the client and my COO hat, the engineer in me was calling it. Something didn’t feel right.

He asked: do users really need to communicate with one another? What's the reason?

The client said it was to get users to agree on a time and a place to meet, but my inner-engineer knew there was a way to create a more efficient User Experience. After discussing this with the client, I was able to chop down the scope and building a customized user experience that specifically only allowed users to select a date and a time with respective UI elements — not giving them a free text field to type into.

In the end, the client didn't pay for an entire in-app messaging system.

Again, the COO in me was fine with the app messaging system – more profit for Incipia, and it would have been easy to build within both the budget and time-frame. But, the engineer in me needed the app to be maximally useful to both the client and their eventual end users.

Where Technical Prejudice Can Harm COO & Client Strategy

When discussing an idea with a client, it's very likely that they, themselves, have not considered all the details involved. And any thorough developer in a discovery meeting will likely be running a background thread, thinking through ways in which the features being discussed might be implemented; they'll be thinking through the details. Which is totally normal for a passionate developer!

But it's dangerous to dive into them too early on, especially if the client doesn't have a strong technical background. As an app development studio, what's most important during early stages is to reflect an understanding of the client's needs, and the competency and experience to deliver what they're asking for.

Case Study #2: A Resolution Center Nearly Stymied by Technical/Strategic Tension

Another app we worked on required cashless transactions in the initial MVP release. In turn, due to limitations of the payment processing framework we used, a resolution center was merited, giving users a way to dispute transactions.

The client knew it this was necessary, and agreed to add it to the scope, which was all we really needed at the time — a green light so we could focus on moving forward with the contract.

The engineer in me was excited. I hadn’t previously built a resolution center as such, and dove right into integrating it into the system in progress.

Soon after though, the COO in me began to feel uncertain about assumptions that were made. It was as if he was looking over the Engineer’s shoulder the entire time, micro-managing me as I programmed. He was constantly asking questions like: When a user files a dispute, should they be able to resolve it? Should an admin be the only type of user who can actually resolve a dispute? What does the interface look like on the user's end for a dispute that's been filed? Does it reflect some sort of state, like "In Progress", or "Resolved"? How much data should we include in the dispute model? What's absolutely necessary and what's just nice to have?

Thus the COO in me started sweating. He began wanting to halt development. Reach out to the client. Have several meetings with all the engineers. And basically not move ahead at all until everything was 100% clear.

Thankfully, my Inner-Engineer spoke up and acted as an advocate for the development process itself.

Inundating the client with these questions at such an early stage would have been unproductive for everyone. All that really mattered was that we were capable of building a system for handling disputes, and whatever that actually looked like would shape itself as time went on, provided we trusted our time-tested development methodology. He new that a lot of the questions we could have spent time answering at that point were only going to answer themselves throughout the course of development, which they did.

The client was pleased with the initial build, and we were able to make improvements as time went on – both under budget and on time.

Side Note: This example also supports why fixed bids are not prefered: they prevent a full expression of the agile framework and its ability to create insightful products

Main Points

To end this piece, I just want to summarize the main points:

1. Digging into the details around reasons for which a client desires certain features can reveal alternative solutions that may reduce scope, thus reducing cost and time.
2. Technical details aren't always worth getting caught up over during early stages, because having the smarts and resources to figure things out is really what matters.
3. Being an Engineer has massive advantages to understanding client need and building great products. However, if not appropriately put in check, my Inner-Engineer can hold me back as a strategic COO by making me focus too intensely on details.

Be sure to bookmark our blog, sign up to our email newsletter for new post updates and reach out if you're interested in working with us.

Incipia is a mobile app development and marketing agency that builds and markets apps for companies, with a specialty in high-quality, stable app development and keyword-based marketing strategy, such as App Store Optimization and Apple Search Ads — check out our new e-book on ASO by clicking here. For post topics, feedback, or business inquiries please contact us, or send an inquiry to hello@incipia.co.