Over the years, I have learned and observed others at Atomic Object anticipating the needs of a client to ensure that, if an issue does arise at a future date, we can react quickly and minimize any complications. Taking the time to anticipate future needs and putting yourself in a position act on them shows that you give a shit and have the client’s best interest in mind.
Here are a few needs I think are important to try and anticipate.
Anticipating Capacity Needs
Building software products is not an exact science, and every client has unique requirements and constraints. That means staffing Atoms is not an exact science, and it can be very fluid.
It is important to (and I’ve seen our upfront team do this regularly):
- Anticipate capacity needs for a client before they have officially asked for it.
- Building in scheduling buffers for existing projects based on A) their current progress or B) what history told us with regard to a certain client.
Anticipating Technical Design Needs
Since we are experts at creating software products and understand what good technical design is, we should take it upon ourselves to anticipate important longterm product goals that have a big impact on technical design.
Example
I was apart of a collaborative kickoff with a client where one part of the product was a scheduling application that could “reserve” remote devices. During the kickoff, the client continually mentioned that “in the future” the application would need to expose an API that would allow their larger client with their own scheduling software to integrate with “the API.”
I made sure, from the very beginning of the project, that we created our entire product (including the reservation application) against an API instead of the traditional database backend.
Result
- Their first interested client wanted to use the API instead of the reservation application we built.
- Multiple applications have since be written against the API.
- Certain manufacturing process requirements for the device would have been orders of magnitude more expensive if there wasn’t an API available.
Anticipating Problems in the Field
Creating custom software is difficult, and in spite of good technical design, automated tests, and exploratory testing software, will go into the field with undiscovered issues. It is important to anticipate this and equip yourself with tools so you can react to issues quickly and resolve them as soon as possible. This makes the difference between a happy and disappointed client.
Example
Recently, a product we’ve been working on went into beta, where it was made available to a number of users. Despite the extensive amount of testing that we do, there’s always a chance that an issue may arise. Given that, we always build in mechanisms that will alert us if any problems arise when people use it.
Unfortunately, one of their first beta users had a unique account that caused our mobile application a lot of problems. We saw the issue via an e-mail and fixed it before the client contacted us. We had a new build going out just as their panicked e-mail arrived. Despite a mistake we made in our application, we built trust with our client because we reacted before they could even shoot off an e-mail.