The Devil is in the Detail
When my co-founder and I decided to make Incipia a full-time operation, I was a software developer. During previous jobs I spent almost all of my working hours writing, talking about, or thinking about code. I lived and breathed it because I was, and still am, very passionate about programming. Admittedly though, my passion blinded me from thinking strategically as Incipia's CTO.
Over time I was 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. Overall, being self-monitoring and constantly willing to adjust my tendencies has been tremendously helpful in growing as a business owner.
The Devil Is In The Detail
Programming must be one of the most detail-oriented skillsets in the modern world. At the end of the day programmers are responsible for writing code with the intent of minimizing bugs and preparing for unpredictable changes in direction, and that requires a thorough attention to detail. I've learned that there's a time and place for it in the business world, though. Maintaining a healthy relationship with clients, prospective or current, involves giving a proper attention to detail. I've experienced both positive and negative side effects of being detail-oriented when communicating with them.
Details Can Help
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.
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.
An Example:
In-app messaging — a commonly used feature. One client we worked with thought they needed it. Our question was: why do users need to communicate with one another? What's the reason? In their case it was to get users to agree on a time and a place to meet. We chopped down the scope by 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.
Details Can Hurt
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.
Another Example:
A resolution center — another app we worked on involved cashless transactions in the MPV. In turn, due to limitations of the payment processing framework we were using, a resolution center was merited, giving users a way to dispute transactions. The client knew it was necessary, too, 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.
As we dove into the depths of the resolution center and all the questions around it, I begun to feel uncertain about assumptions that were made. 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?
Inundating the client with these questions so early on would have been bad. 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. 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.
Side Note: This story also supports why fixed bids are not a preferred method, and why the agile framework is a better approach for developing an app.
Main Points
- 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.
- 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.
- As an Agile business, this doesn't mean "we fake it 'till we make it" — we're a confident team who can solve challenging problems that we've never been faced with, and we strive to have an open and honest channel of communication with our clients along the way.
