We partner with our customers to understand their business.
We do not propose solutions until we are sure we have found the right problem. —from the 8th Light Principles of Productive Partnerships
There is a surfeit of good software in the wild. Libraries and frameworks, open source and paid - there are all kinds of tools at your disposal for our client's next project, and they can save you months of development effort. Instead of rolling your own, you can quickly add features to the system with an existing solution.
While these tools can have proven track records of success at any number of clients, that doesn't mean they are right for our client. The tool that you think will save time may end up costing more in the end than writing and maintaining your own solution.
In fact, the availability of tools to solve certain problems may lead to misdiagnosing the problem entirely. Instead of building out a custom version of a tool, it could be that problem can be solved with some automation and a bit of developer maintenance over time.
As software crafters, it is critical to truly understand the problems our clients face. Every use case is important, and these can make the difference between a straightforward implementation and agony every time you touch that part of the system. Coming to the right conclusion can only be done with the collaboration of the client and development.
The CRM Problem
Let’s consider an example that is probably familiar to many. When it comes to CRM functionality, both sides may think an out of the box solution is the best choice because it's a "solved problem". In fact, if you've worked with a CRM, the conversation probably went something like this:
Product: "We need a CRM tool. What about [insert the last CRM you worked with]?"
Developers: "Well, that's easier than us building it from scratch. We can always use the API for the custom stuff."
Weeks later, when product is demanding custom functionality from the tool itself, the developers find out that the API is a mess and doesn't really provide the flexibility needed. In the end, development gets something working, but it's a clunky solution that no one is really happy with, from end user to product to development.
Instead of simply accepting that the problem is that there is no CRM, sit down with the product team and the users to find out what the real problems are. You may find that an existing solution is the right tool, but you may also find you need about 5% of what common tools offer, plus functionality they don't offer, and you can build it yourself. In fact, you could even find that no new user input is needed - the data is being collected already, it just needs a few reports and some automated tasks.
Know the Capabilities of Your Tools - Spike it
So you know the business needs. Even then, most of the time you just don't know if a piece of software is going to work the way you expect. Take the time to gain certainty, and spend time on a spike of the functionality.
Over the course of a day or two, build up a sample app to see if it can handle all of the use cases of the business. If it works, great! You can move forward with confidence, even though it cost a bit more to get that confidence. If it doesn't, well, you're back at square one, but at least you didn't spend the time trying to get the software to work before having to backtrack later.
A Stitch in Time
No matter what the solution ends up being, it's important to find the actual problem before proposing a solution. It can be time consuming to understand the needs of the business. In some cases, it could be that no one actually knows what the real problems are. However, a few hours of investigation can save a week's worth of work, and a week's worth of interviews and observing could save months. A software crafter recognizes that no matter how much code he or she writes, it's all for nothing if the real problems aren't solved.
