In a recent LinkedIn post by Islam Midov, I saw the line “engineering without user context creates beautiful solutions to wrong problems.” It really hit home with a theme I have believed for years. No matter how well the specification is crafted, the people who write the code have to know more about the problem they are solving than will come through in a spec. It is not enough for an engineer to say ‘just tell me what to build,’ and expect a product manager to feed them everything they need to know.
One of the reasons many offshore development projects get into trouble is that the coders blindly follow the spec without any understanding of real users and the actual use case. During the coding effort, there are always moments when the coder has to make decisions about which way to go or how to represent something. If the coders are mercenaries who are disconnected from the actual business, things tend to go awry.
On the other end of the spectrum, when engineers are given a general problem statement and afforded total freedom to innovate and build a solution, if they are not deeply engaged with real users, we often get “beautiful solutions to wrong problems,” or we get ‘engineered’ complex and unusable solutions to the right problems. Unless the customers are engineers, there is frequently a disconnect between how an engineer envisions an ideal user interface and how real non-engineers actually do their jobs. What is easy and straightforward to an engineer may be complex and confusing to a mere mortal user.
Some of the best applications have been created by entrepreneurs who were doing a job and had a vision to introduce an application to do it better. They personally built their first product and imbued it with their deep understanding of how real users would use it to accomplish their jobs. Instead of ‘user led growth,’ this is really ‘user led invention.’ The challenge is how to preserve the user connection when the engineering effort expands beyond the original entrepreneur to a team of professional developers.
I have always been a fan of forcing engineers to come out of their shells to actually interact with customers and prospects. There are several layers of benefits that come out of the process:
Improved usability is the first benefit. When an engineer understands how a customer uses the app, it is like a lightbulb goes on for the first time. It may not be a scientific approach to usability testing, but I have seen engineers race back to their desks to rework elements of an interface after spending just minutes with a real user. Formally engaging with customers to test usability is a profession with real science behind it, but for most early stage companies, it is beyond their budget. A simple approach is to assign engineers to work the customer service desk for a few shifts or on a routine rotation. When they see the mistakes user make, or hear users present their confusion and challenges, it provides context to make things better.
Improved application fit is the second order benefit. When engineers interact with customers, they hear the pros and cons of how their application solves the users’ needs. This is an element of ‘product / market fit.’ Beyond usability, application fit reflects how complete the solution is, how it integrates into the user’s organization and computing environment, and how it delivers value to customers. Customers are not shy about what they want an application to do for them, and it is important for engineers to hear it all and have the opportunity to engage and ask questions.
Expanded long-term vision and ‘future proofing’ the architecture is the highest order benefit. When engineers only understand the problem that is immediately in front of them, they miss the opportunity to leave room for growth. In a simple form, if they build the product for the U.S. market, and hard-code it with English, they limit the potential for a global rollout without significant re-coding. Language, currency, timezone, and date format are all well understood limiters that good engineers know to avoid. The more important elements of future-proofing come from a deeper understanding of how customers see the future, and where they want the platform to expand. The buzz-words for this are ‘product led growth’ which really ought to be called ‘user led growth.’ The concept is to let the users guide where the product goes. When engineers interact with customers and gain an understanding of the customers’ vision of the future, they build that understanding into their architectural choices and everyday coding.
I am a huge advocate for the role of product management, and I believe the product manager has to be the one decider who is ultimately accountable for the success or failure of a product. So having said that, none of what is described above is intended to usurp that authority. In fact, the product manager should be arm-in-arm with the engineers as they interact with customers. The rapid pace of markets today means that product managers do not have the time to labor over every detail and nuance of requirements, let alone specs, so they need to have a mind meld with the engineering team and be able to speak in short sentences while fully communicating. An engineering team that has a deep understanding of the customers’ needs and wants is vital for efficiently creating beautiful solutions to the right problems, instead of solutions that lack product / market fit.