This week we’ll be focusing on how you can add business value. When you’re working on your tasks this week, try to take some time to understand how what you’re working on is adding value to the business, whether it’s planning, writing code, or reviewing other developer’s code.
So what even is business value? If I had to pick one sentence to describe what business value is, it would be this: Business value is all about solving problems for your users. It sounds simple, but there’s more to it. It’s easy to forget, but your users may be paying customers, external partnerships, or internal users within your company. Whoever your users are, as long as you’re solving problems for them, you’re adding business value.
The thing that most developers have a hard time understanding early on in their career is that the code doesn’t matter as much as you think it does. Your users don’t care about what programming language or framework you use, or what design patterns you implemented in the codebase. All they care about is that your product solves their problem, that it is bug free, and that it’s reliable.
So how do you solve problems for your users? Focus on their pain points. Be relentless about making things easier, cheaper, and faster for your users whoever they may be. Don’t get caught up trying to write perfect code or finding the perfect abstraction. If the code is good enough (and it solves their pain points) ship it and move on. If you’re constantly refactoring code until it’s perfect, you’re just wasting effort to make the code better without adding new value for your users.
So how do you know what your user’s pain points are? That’s up to you to learn as much as you can about the domain of the problem you’re trying to solve.
Internal users
If you’re working on an internal tool, you should be able to reach out to the users of your product and ask them directly about their pain points. Ask them what is most important to them when it comes to using the tool or product you’re building. What frustrations do they have? If they could change one thing about the product, what would it be? How would the tool work if it were fully automated?
There may be opportunities to optimize internal workflows even further if you are able to understand what is important to your coworkers. When building internal tools, your focus should be making it as easy as possible for your users.
Paying customers
In order to truly add value for paying customers, you need to understand why they use your product. What problem is your product solving for your customers? Why is it even a problem for them? If you really want to fully understand your customers, you’ll need to learn the business domain.
Anyone can write a CRUD application that does basic data manipulation for a specific vertical, the real value is in writing software that does complex tasks for your users that they otherwise couldn’t do themselves. The key is to understand why your users need to perform these complex tasks so that you can expand your product’s capabilities to make your user’s lives easier. And the only way to do that is to fully understand the industry you work in and the real problems your products solve for your customers.
I’ll encourage you to spend ten to fifteen minutes every morning this week thinking about your users and how you can make their lives even easier. When you put yourself in the shoes of your user, you’ll be able to think about new ways that you can add business value for them.
🔗 Additional Reading
- Code-first vs. Product-first (thezbook.com)
- You Are Not Paid To Write Code (dzone.com)
If you liked this post, subscribe to the Beginner.dev newsletter on Substack for more great content just like this.
Top comments (0)