Let’s face it: most software engineers struggle with business cases. Most engineers focus too much on solutions, jargon, and details, and not enough on hard-hitting and straight-talking business value. The best engineers, however, know how to speak the language of the business and translate technical projects into real business impact.
So, why is it that some engineers thrive where others struggle?
Now, I know what you are already thinking: “That’s bold! How do you know engineers are so bad at writing business cases?” And the short answer is: because I watch engineers struggle creating business cases every day. And it’s my job to help engineers craft business cases that compel, speak to technical leaders like CTOs and CISOs, and ultimately get projects off the ground. Let me explain…
Gitpod has a free tier, open to the entire world. Which means that we’ve seen over 1 million developers on our platform. Rather unsurprisingly, we get asked every single day: “I love Gitpod! How can I convince my boss that I can also use Gitpod at work?”. Whilst I absolutely love hearing this question, I can’t help but feel how this question has flaws. The question is not really “how can I convince my boss?”. The question is: “How do I show how Gitpod can help my company to achieve its goals?”. And this applies to any developer tool, also.
Today, I’m going to give you the playbook I use when helping Gitpod customers create business cases. I’ll use Gitpod as the example here, but you can easily apply this playbook to build a rock solid business case for any product or tool.
Step 1 - start with the “why?”
When it comes to embarking on any new initiative, it’s imperative that you start to think very deeply about your “why”. What needs are you hoping to fulfill with this project? What is the compelling future you are creating for your organization? Or, what urgent need are you solving?
If you have not read “start with the why” by Simon Sinek - it’s a book on leadership and persuasion. Sinek argues: “People don’t buy what you do, they buy why you do it” and the same is exactly true when it comes to building business cases. If you are having issues you know a cloud development environment can solve for - your peers and managers are simply going to want to know “why should we purchase this?”
You should have this thought fully fleshed out. Does this help achieve overarching business goals such as shipping product faster? Does it help with your developer experience initiative? Does it help with a mandate around security? Does it help strengthen the story of your cloud first-approach to infra and tooling? All of these questions help tie back to why purchasing this tool impacts goals that your leadership are thinking about.
Another way to help tie back to business goals is by explaining the problems and pain you are feeling today. Use this as an anchor to justify how this tool’s solution is going to help with the given problems. We will circle back to this as it’s part of the business case - but before doing the work - you need to understand how to articulate the why.
Step 2 - research and requirements.
Google is your friend. Forums are your friend. G2 is your friend. Reddit has good info. Find out who the top vendors are and research them deeply to determine who you may want to partner with. How should you decide?
There are 2 ways:
- Social proof (reviews, ads, word of mouth)
- Trying the free version of the product to get an idea of what that product is like.
After you understand what vendors stand out - make a short list. Looking at 12 vendors is a waste of time - in most cases only 3-5 vendors will be best in class, the rest will be column fodder. There is no reason to subject your team to look at 12 vendors just to find out the top vendors were the most popular for a reason.
Then comes the hard part - creating technical requirements.
For CDE vendors, you should understand if they:
- Support connectivity to cloud and on-prem resources
- Work with all your IDEs and editors
- Are extensible with your existing tooling
- Support your SCM of choice
- Connect to your security tools (SSO, VPN, etc)
For CDEs, this is not just a tool for developers, platform, security, devops or engineering leadership. It is actually a powerful platform that will affect all of them - and you should absolutely find out what is important to each stakeholder group and invite them to look at your requirements list. I call this out as this is the case for many developer tools now, and leveraging the wants and needs across cross-functional stakeholders, will only strengthen your case.
Step 3 - engage vendors.
You have a reason for why, you understand your company's technical requirements across stakeholders and you know who the top vendors are in the space. It is time to (take a deep breath) - talk to salespeople.
As someone who has been a sales person for over a decade - I promise we are not all bad. Remember - the more open you are with your account executive - the more they can help you and that is what they are there for. They will run a process called discovery to better understand the current state of your business, your pain points, internal structure and tech stack to determine if you are a good fit for their offering.
If you come prepared with your technical and business requirements - this will tremendously help them assist you - doing this work beforehand will also allow you to stay objective in your evaluation and not get a vendor to suggest a checklist that only aligns to their offerings.
Vendors should be helpful to you in this process - but they can only be helpful if you give them relevant information and access to the team to make a consensus driven decision. Taking a first call with just yourself is fine - but be prepared to invite other folks from your team to the demo.
Step 4 - shortlist, test and start the internal procurement process.
You are now at the proof of concept stage. Something that we refer to as a proof of value here at Gitpod - as successful evaluations consider both technical and business requirements.\
Before you dive into a POV with anyone - it would behoove you to understand your internal procurement process - especially if you have not done this before. A typical procurement process will need the following:
- Alignment across all teams that the issue is real and works within their boundaries.
- An executive buyer (someone who can sign a contract and has access to budget for a tool).
- A security review - your team likely has a questionnaire for software vendors to complete.
- Contacts from procurement and legal that will need to be involved to negotiate on terms and commercials of the agreement.
You can never start this process too early. Vendors can assist you in navigating this process, but only introduce vendors you like and trust.
In the POV stage, it is important to test our use cases that solve for your “whys”. Deep technical testing, combined with commercial evaluation will set you up for success. You will need to carve out employee time for these projects. As a rule of thumb - you should never, ever, POV with more than 3 vendors at once. It will be very clear what products are technically sound and which products are not a good fit within the first few days of getting it up and running.
During the testing phase we recommend devoting at least 8-10 dev hours to each vendor you are evaluating. It’s important to give each platform a rigorous trial to make sure that you’re comfortable with installation, setup, and usage.
For CDEs specifically - there should be a big emphasis on developer experience - as you are changing a workflow devs have known their entire career. Get feedback from them - as end user adoption is the most critical part of a successful implementation. Here at Gitpod - we send out engineering surveys before and after testing to measure results (link content here).
Step 5 build your business case
You should have nailed your “whys” and identified some main use cases that you validated are solved for with your vendors. Once you have identified your emerging winner - you have to build out a business case with that vendor.
In the business case you should have:
- A history of the why.
- Metrics around how pains of local development are hurting staff today.
- A return on investment calculation
- A summary of why you chose that specific vendor as preferred and some high level information about them - including price.
Your vendor should help you put the above together. Here at Gitpod, we help our partners with the business case and have a very detail oriented ROI calculator (contact us if you’re interested in a copy) that tells you how much money you will save by implementing a CDE with your data inputs.
Step 6 - enjoy.
Take a deep breath and get ready to implement and solve your problems. Purchasing a CDE doesn’t have to be a lot of work if you partner with the right company and the benefits will make you and the team look great with less work!
If you have any questions feel free to reach out to the sales team at Gitpod.
Top comments (0)