Software developers’ three customers: Enable their success
April 17, 2021 876 words 5 minutes to read Last Updated: November 27, 2021
Successful modern software development organizations focus on value-added activities while seeking to eliminate waste. Conceptually, it’s easy to grasp this strategy. But the move from strategic to tactical isn’t always straightforward.
Some developers feel isolated, especially in large organizations where rigidly delineated roles dominate. They may rarely witness any direct impact from their contributions. They’re “upstream” of where the return on their efforts accrues.
Meeting the needs of the customers
Sound all too familiar? No worries. If you’re a software developer, our guidance will buck up your feeling of self-worth – and ensure it’s justified. Developers just need to meet the needs of their three customer groups. Understanding your customers and their needs and meeting those needs will make you a rock star!
Along the way, please remember you need to do more than provide short-term satisfaction. Your successful efforts should enable your customers’ success.
Begin by asking:
- Who is “the next person in line”?
- Who buys our product or service?
- Who actually uses our product or service?
Next in line
For the first class of customers, identify who processes, tests, evaluates, or pushes developer code contributions.
How can you enable the success of those folks? For QA customers, developers can communicate clearly about their code changes. Specify the scope of the changes and expected functional results. Where does functionality change? How? Are there exceptions?
Include other software developers in your list of customers. Depending upon your organization, they may be tasked with reviewing your code. Even if you don’t commonly perform code reviews, other developers will surely access your code for maintenance and updates. Help them succeed by writing clean code. Strive to create code that people, not just computers, can understand. When clean code isn’t enough, add comments. Comments tell other developers about context, special assumptions, and difficult algorithms (How to Document Source Code Responsibly).
Portable code and Docker containers can facilitate successful outcomes for operations staff. The movement from VMs (virtual machines) to Docker containers has been rapid and widely successful (Yadav, et al., 2018). Docker containers make it easier to manage and deploy applications. That ‘ease’ helps maintain happier operations customers.
Of the three categories of customers, this may be the most difficult for developers to consider. Who actually purchases your software products and services? These decision-makers might be far removed from developers. When a systems development project is initiated, the systems development team needs to articulate an unambiguous set of goals, objectives, and anticipated ROI for the project. Thus, all stakeholders will possess a shared vision of the resultant system’s likely contribution to the benefits derived by the organization. DevSecOps and modern perspectives on software compliance have brought some of these customers’ needs closer.
Is billing intuitive for these folks? Do the products and services meet required security and compliance requirements for procurement? Are there established mechanisms for proving return on investment? Are contracts and legal logistics efficiently and effectively handled?
Historically, end users have enjoyed the most attention of the three developer customers. Human experience, including usability, became a major focus during the 1970s growth in personal computing. Software development spawned the UX profession, which codified user experience principles. So, most developers are working on those aspects of customer success.
But successful end-user outcomes require more than a kick-ass product. Consulting, documentation, training, coaching/mentoring, and other professional services are often requisite complements to successfully adopting software products and services.
Customers may be challenged to identify and articulate their own needs. Concomitantly, customers may consider their needs to be so self-evident that many lack an understanding of the significance of these needs. In some cases, customers may also resist a new change because of the learning commitment required. Finally, customers may oppose new systems or changes, since they will need to abandon existing practices, processes, policies, and routines, potentially upsetting the power structures in the workplace (Paasi & Valkokari, 2010).
Consulting projects encourage the correct customer-product match, and documentation and training help maximize ROI on that match. Developers can add cross-functional value to such efforts.
Don’t be surprised when a customer in any of the three categories can’t fully articulate a resolution for their needs, problems, issues, and challenges. However, these same customers should know what will make them successful. As such, thinking about desired customer outcomes will better drive developer activities.
Senior management support and commitment to active business leadership are critical success factors for achieving those desired customer outcomes (Doherty, et al., 2012). Translate these desired customer outcomes into products, specs, documentation, artifacts, and assets that you can deliver. Consider taking an inexpensive course that will permit the systems development team to improve the initiative’s effectiveness by showcasing the benefits of the products and solutions to customers: B2B Marketing: Messaging With Value Proposition Design.
Doherty, N. F., Ashurst, C., & Peppard, J. (2012). Factors affecting the successful realisation of benefits from systems development projects: findings from three case studies. Journal of Information Technology, 27(1), 1-16.
Paasi, J., & Valkokari, P. (2010). Elucidating the fuzzy front end: Experiences from the INNORISK project. VTT Technical Research Centre of Finland. http://www.vtt.fi/inf/pdf/publications/2010/P743.pdf
Yadav, R. R., Sousa, E. T. G., & Callou, G. R. A. (2018). Performance comparison between virtual machines and docker containers. IEEE Latin America Transactions, 16(8), 2282-2288.