.png)
Selling to leadership is a great skill to develop that will set you apart from your colleagues, drive meaningful change within your organization, and help you make strides in your career. In this article, I’ll discuss how to sell software development within a non-tech environment. Covering your bases before, during, and after the pitch will help you sell within your organization and propel new projects forward with confidence.
Align initiative to reach quarterly & annual goals
Every company has goals. COVID-19 may have derailed some goals and expedited others. I’m sure you have a laundry list of things to achieve this quarter, by year-end, and 3-5 years out. Technology will undoubtedly play a part in helping you achieve those goals, but perhaps your organization is resistant to thinking of itself as a technology company, has had past tech projects go awry, or genuinely doesn’t know where to start with its technology investments. Believe it or not, this is normal in my experience working with super successful corporations.
The best way to get started is to convene your stakeholders, which may consist of your IT, legal, and/or business units to discuss the goals in front of you, and understand their needs within the organization. Remember that your legal team will have different needs than your IT group, and all are valid at this point.
Understanding their needs to get to an eventual “yes” starts with a series of exploratory conversations. Furthermore, align your business case toward known near-term and future goals for your business unit. Below is a recent example of the lofty goals I’ve discussed with a successful corporation.
“We want our services to move from consulting and deliverables-based engagement to a platform service to become infinitely & digitally scalable.”
AKA: “We want to change the way we currently operate our business, how customers engage with us, and increase our market size from local to global.
This is a large endeavor and one which will indeed require technology investments to achieve. My point is, align your goals to the goal of the company before all else.
Due diligence on your concept
Leaders will often make decisions off of gut feelings rather than data. It's nearly 2021, and time to break some old habits. There are a multitude of ways to complete due diligence on your concept either by doing this internally or externally via hiring a team. You WILL get pressed by your leadership when you ask for a bunch of money to build new technology, and they are smart investors.
They want to know that what you’re building will work before they write big checks. Luckily, there are ways to do this that will align your stakeholders, bring clarity for everyone, and de-risk your approach. Sound too good to be true? It's not. It's what digital product agencies do all the time. It’s better to spend $50-$100K validating your direction than six figures or millions building the wrong solution.
What's in your mind's eye will not be what you end up building 100% of the time. This has been the case with every client project I have worked on to date. Due diligence on your idea is going to make you smarter, impress your team, and ultimately help you solve the right problem(s) for your customer.
Utilizing design prototyping or a design sprint to help validate or invalidate your direction
Corporate leaders are infamous for claiming, "our customers don't know what they want until we give it to them." For a lack of better words, this statement is total BS. Yes, your customers do have opinions. Are you willing to leave your desk/office/comfortable spaces to hear them out? Engaging your customers early in your strategy and design process is invaluable, and most times they’ll help you out for free as a favor.
Imagine showing stakeholders recorded user interviews reacting to your design prototype. How impactful would that be? There isn’t anything more impressive than demonstrating that you know that what you are designing is solving a real need for customers and they are asking when it will be ready.
This is the fastest way to getting to a “yes” on your high dollar build phase and a promotion. This process works for B2C & B2B solutions. In fact, the B2B solution is where we’ve seen this work best because a handful of excited clients could cover the entire next phase of development.
More on Design Prototyping.
More on Design Sprints.
Iterate in design NOT code
You wouldn’t start construction on a new building without a crystal clear architecture plan, would you? Changing a building halfway through the construction process could be almost as expensive as building a new one. Nowadays, tools like Figma allow you to create realistic design prototypes that look and feel like a real web or mobile application that potential customers can react to. Iterate as many times as you need to in design NOT code. This will help control costs, expectations, and give you more confidence in your direction!
High leverage solutions & 3rd-party tech
In 2020, it's rare that an entire software solution is written in custom code. Smart leaders and developers look for high-leverage solutions that they can integrate into their software in a custom way. It may not be a forever solution, but it could be a smarter way to get started, test what you’ve built in the market, and help you put points on the board early. No one wants to wait 12-24 months for you to get your first customers – that’s too long. Your project will get put on the back-burner or dissolved.
You should shoot for early wins within your first 6 months of development. If the team you’re working with says it will take longer, they’re probably right. Reset expectations on low effort, high-value solutions and figure out what you can do to get your organization some early wins. Sometimes that means paid customers. Other times its internal operations and users, or a mix of a lot of small wins your stakeholders need to see. Bang the drum and be the champion of learning over perfection.
Set metrics & don’t move the goalposts
Believe it or not, your organization likes to set metrics and then move the goal post. I see this often with corporate clients. Once teams are aligned and development has kicked off, the metrics that were set for the project were either the wrong metrics or no longer relevant. When your plan no longer aligns with the current goals of the organization, you will have a rogue project that needs to get with the new plan.
Now, what is best for you and your performance could be in opposition to what is best for the project. Simply put, you MUST set metrics at the beginning that are meaningful to the organization and align with the strategic plan. If you set loose metrics, the goalposts will move and you risk your project being questioned – or worse – dissolved. I’ve seen this happen several times, and it can be prevented with proper planning and documentation upfront.
Measure the ROI over a 4-5 year period and consider the total cost of ownership
Most goals regarding the ROI of a project will be measured in operational efficiencies, scalability, net new revenue, etc. As murky as it is to project out 4-5 years, you need to. There aren’t software projects that are home run investments overnight on a 12-month horizon (please don’t kill the messenger). They’re capital intensive endeavors with heavy upfront investment, usually from Cap X budgets or pulled together from sludge funds like the marketing budget. If you haven’t read my ROI & TCO blog posts, pull them up and dive in.
Beyond scrounging together some miscellaneous budgets from around your organization, you will most certainly need a budget set aside specifically for this endeavor. If you’re mid-year budget cycles, you may get pushed out to the next budget cycle or beyond. Thus it's important to be straightforward and realistic about what you’re going to need moving forward.
Internal/external training and education
Say you get to a point where your product is now ready to launch. Are you prepared to retrain your clients, staff, and leadership to use the software? What is your change management strategy? Do you have customer support and bug reporting ready to go? Are you using a tool like Heap for analytics in your product? Are your sales staff familiar with the product?
The more you can think ahead to supporting users as they onboard into the new application, the better things will go as you launch and scale. If you don’t support users, they risk abandonment from the platform. The real work begins when people start using your software solution in real-world situations. You will learn so much if you’re ready to listen and learn.
Product support & support roles
Oftentimes, corporate teams don’t have the support roles they need in the form of customer service support as well as product management. Creating these roles is foreign and new to companies that don’t view themselves as technology companies. But you will need these roles. Months before launching the product, you should discuss hiring these roles to support the product once launched. Don’t wait until it hurts too much. These are important roles that can make a world of difference in the success of your product and the future iterations it will take.
Repeat
Now that you’ve done it once, you can do it again (probably twice as fast as before). You understand how to do this within your organization, you’ve got several notches in your belt and leadership trust to boot, and you’re the go-to person to foster and bring new technology to life. Go do it again!
