Why and how to find out what creates value before you start coding a solution
In this article, I'll show you what the #valuefirst mindset is, how you - as a developer, digital entrepreneur or maker - can apply it, and I show you different ways of adding value besides coding tailored software solutions.
This article goes way deeper than one of my previous articles about creating value as it provides in-depth information, examples and actionable content regarding obtaining a #valuefirst mindset.
I’ve had my share of consultancy work in my 16+ year career as a developer .
During that time, I evolved from coding little tasks and focussing on grasping the problems that people might have towards learning what the business case for creating a problem was like.
As I got down my career path, I found out that diving going straight for the problem and thinking about the solution so you can define the answer and go at it in code behind your laptop might just not be the best way to go at it.
Nowadays, I truly believe that understanding how you can provide the best value is the first step in the process of creating a great solution.
I can now see how I gradually got to where I'm at today. How I evolved from being a programmer, towards a consultant, to focus on providing value first.
Let me start by walking you through these stages.
Being a developer, it is very tempting to dive into the IDE of your choice and start creating some awesome code.
It’s what I see most beginning developers tend to do.
Don’t get me wrong, I love that awesome feeling when you’re spinning up a new project and getting the chance to build something from scratch is an awesome experience.
It fits right into the core of a developer’s comfort zone.
But what makes you feel comfortable, isn't always what leads to the best opportunities. Nor does it provide the best value for the people you are putting your mind at work for.
And I’m not saying you should never dive right into the code.
For example, when you’re educating yourself on a specific tool, library or coding style. Diving in and coding is the best way to learn.
Or for proof of concepts (PoC’s) or small solutions that don’t need to scale or be maintainable. Go ahead and hack away.
But as you’re in the business of developing for a longer period, you’ll find out that most companies are best helped when you implement solutions that are maintainable, scalable, future proof, and what not.
That are the kind of solutions that need a well thought out setup so they are sure to meet the requirements that they need to confirm to.
When you’ve seen enough of these bigger solutions, that is also the time when you often slowly roll in one kind of a consultancy role or another.
As you evolve from a developer that only codes to someone who tags along with sales (or another department that engages with customers and prospects) to sit at the table and talk with people.
Your role evolved from writing code to find out what kind of solution might form the best solution to their problem.
You start to learn to cut through the b.s. and jot down the important factors.
You use techniques like The Five Why’s to find out if the “solution” that a manager at BigCorp Y already thought of for their problem will solve their challenges.
And as you get better at consulting, you will start to unravel the mystery of the core problem that they’re facing faster and even better, so you can think of an objective, clean solution that will let them focus on their core business instead of defeating or bypassing the issues they are facing.
This is a great place to be in, and I enjoyed providing people with advice and software solutions very much.
But what if I told you that you can do one even better?
What if by focussing on providing value instead of providing the best software solution will help others even more?
By focussing on the value you stop thinking about a problem as something that needs to be supplied with a coded answer or any customized effort in general.
The process is similar to the consultancy angle. You (and potentially a colleague) go to a business or individual who wants to have a problem solved.
Most of the time they have biassed expectations and demands, like:
we need a web/mobile application to do X, Y or Z
there’s nothing out there that fits our needs
the solution needs to fit our budget of $ XXXXX, XX
we need your solution to be usable in the next five to ten years
But instead of thinking along with their given direction ( I don’t say ignore it, write it down but don’t let it limit your mindset), I dare you to take advantage of the objective, uncluttered mindset, and expertise that you bear.
Here are some example questions you can ask to find out where the core *value *comes from on their end:
If you solve this problem, what value does it provide? (ie: does it save you time, reduces cost, increases margin and/or revenue
Does it make things easier for people and for whom? (ie: for the customers or employees using it/management/administration?)
What is the alternative right now; how are you bypassing or solving this at the moment? (ie: doing things manually, using Excel, using a whiteboard, ignoring it, ..)
What made you think of developing a custom solution?
What aspects AKA quality attributes are most important to you and why? (ie: see a list of quality attributes here)
Are there any changes in your processes or architecture coming along in the upcoming period that might affect or improve your current situation? (to find out if they need a short term solution or a fundamental part to support their services and/or processes)
I sometimes find myself in a spot that I need to explain why I ask these kinds of questions. Most people are accustomed to a developer asking questions so he/she can start thinking about developing a solution.
“I already thought of the problem, I want you to build X” and “You’re not known with the specifics of our business, so let me worry about that” are things I have been told earlier.
I always ended up helping them out by thinking about how I could provide the most value instead of just building what they want just a regular customer-supplier.
So, to open up the conversation and guide it towards a #valuefirst focus, you might need to introduce your questions.
You can do this by indicating that you, for example:
are trying to understand what the* core value* is
want to understand how their given solution/direction (if any) came to life
are using your objective mindset and expertise to see what alternatives might be applicable
Most people appreciate that you’re putting in the effort to think alongside with them and that you’re trying to truly grasp what they are trying to accomplish.
And that is when the #valuefirst mindset starts to kick in.
You get to talk with the people on the other side of the table and work together on unraveling the problem and finding out what works best for them, and — you’ve probably guessed it by now — what provides them with the most value.
If you understand what provides value for a person in his or her context, you can look at solutions for any problem and might just find out that coding a new tool isn’t going to be the best answer to a problem.
I truly believe that the differentiator for a software developer isn’t “writing code” anymore. Not even “writing awesome clean and pretty code”.
For a business, their customers or any end-user of online services, mobile apps or even an IoT solution, the most important thing is that it provides them with value.
These are some of the most hands-on reasons and ways in which any solution might provide people with actual, recognizable, *raw value *by:
saving money or increases money revenue
giving information when it is needed
making a process easier or reduces risk by human behavior
automating something entirely so people can shift their focus on other (more important) things
None of the above-mentioned means of creating value define any limitation or point into any direction of having to code custom software.
Here are some ways in which the core value could be provided:
Changing a process or setup slightly to open it up to existing solutions or tools
Defining a simplified manual process and use less expensive manpower
Using existing solutions (ie: SaaS or existing apps) to replace a part of the current implementation or process
Creating a solution with no- or low coding tools to create a quick fix for temporary usage (ie: when things are going to be changed in a year or two)
Tie together their current tools and/or data with external API’s or tools with connecting services like Zapier.com (useful for plugging in functionality and keep the current architecture almost untouched)
Pointing people to the right expert that has solved similar issues many times so they get the best solution possible
Okay, but I don’t see custom code in this list. Is developing custom solutions deprecated then?
Let me be clear on this: ABSOLUTELY. NOT.
I’m just saying that going to meet with people and assuming that a custom developed solution is going to provide them with the most value isn’t the best way to assure they get the most value.
As technicians, we often tend to be early adopters, and need to have a clear understanding of what tools are out there.
We also need to be up-to-date on the best practices being used today and the trends and upcoming *next thing *that is going to help people and companies to accomplish their goals.
Lucky for us, those aspects also make us great advisors on all sorts of solutions besides the one that we love so much that we chose it as our profession: software engineering.
There is a quote that is very suitable here:
There is a place and time for anything — Gloria Tesch
Custom Solutions have their place. And they are not an alternative to the #valuefirst mindset, but a strong part of it.
What I’m trying to get across in this article, is that coding custom solutions aren’t the only way to provide value.
I know there are a lot of software development companies that just want their engineers to write billable hours.
Companies that want to sell big ass development projects for custom-tailored software solutions for big corporations.
Photo by Pixabay
And, as long as the value that those companies provide is large enough for their customers that it enables them to the accompanying price tag, those scenarios are even be fine, too.
But custom software should not be the goal on its own. Providing value should be the ultimate goal.
When there are clear grounds as to why custom software is needed, it is fine to go go down that path.
The following motivations are perfectly valid examples of reasons for developing custom software:
having full control of the specifics
future (strategic) developments
full integration requirements
regulations or other restrictive settings
When that’s the scenario you’re in, your added value lies in finding out what solution and setup provide the most value.
By using the #valuefirst questions and using techniques like The Five Whys, I often get a lot of background information that will help to outline a solution that provides great value.
The bottom line of what I’m trying to tell you is this:
If you want to stop selling code and throwing it over the fence, and if you want to escape the harsh structure and old-school customer-supplier relationships that tend to let you work hard for a market conform price, trying to focus on building customer won’t get you very far.
If you want to provide value, you’ll need to think alongside parties that want a solution to their challenges.
Talking with people and finding out what will help them the most is about finding out what provides them with the most* *value and thinking about what type of solution can provide that to them while keeping their context and situation clearly in your eyesight.
Get in the field together, find out what the goals are, and how to get the best value out of the game.
If anything else, I hope that this article provided you with some hands-on insights, an actionable approach, and the very basis of what I call the #valuefirst mindset.
Code Hard, Ship Harder 🔥
This article was also published on Medium