Selecting New Technologies
Every product manager builds their product on top of some set of technologies (commonly known as a tech stack).
As customer needs and organizational needs continue to change, product managers may find that they can no longer solve these needs through product iterations alone. In cases like these, PMs are faced with a difficult decision: whether to switch out parts of their tech stack.
This decision is critical to the long-term health of both the product and the organization, and usually appears at critical inflection points – such as when a startup has found product-market fit and is aggressively scaling, or when a suddenly finds itself inefficient and unprofitable.
I’ve had the opportunity to witness a couple of these decisions firsthand, and I’ve had the privilege (and pain) of leading such a decision myself. Since the decision to change technologies is rare but high-impact, I’d like to share my frameworks and best practices for selecting and implementing new technologies.
I’ll address this topic into two separate articles: 1) selecting new technologies, and 2) implementing new technologies. This article will focus on selection.
As a side note, I’d like to point out that many of the frameworks below are valid across many different kinds of product decisions.
As product managers, we should strive to leverage reusable frameworks and guidelines rather than blindly memorizing formulas or processes. That way, our experiences build on top of one another and enable us to tackle broader and deeper challenges over time.
Now, let’s dive into why organizations decide that they need to evaluate new technologies.
Why Switch Technologies?
Based on my experience, I’ve found that product managers and executives usually make the call to switch technologies based on at least one of the three following reasons.
The first reason is that the functionality of the current technology no longer meets the needs of today’s organization.
As an example, some technologies do not update or display data in real-time. In time-sensitive contexts (e.g. call centers, customer support, etc.), this constraint is unacceptable.
The second reason is that the organization seeks to evolve in a particular way, and the existing technology cannot accommodate such an evolution in the future.
For example, say that a decided to capturing and analyzing 100x the data that it currently does. Some database technologies do not scale well – and so these technologies may serve the today, but they cannot serve the in the future.
The third reason is the opportunity for efficiency and cost-savings. Simply put, some technologies are much cheaper to use than others.
Note that there are many kinds of costs that are relevant to such a decision. Here are some of the most common cost factors I’ve seen.
Hiring costs – some kinds of developers are more expensive than others. If there are very few developers for a particular technology in your particular market, then they can be very difficult to find, attract, or retain.
Onboarding costs – some technologies are very difficult to master or lack supportive communities and resources. Therefore, new team members such as developers and PMs can wind up needing a lot of time before they are fully onboarded and producing at full output.
Maintenance and integration costs – some technologies may not be easy to debug, or are very difficult to maintain over time. Additionally, some technologies are extremely painful to integrate against other technologies.
Licensing and usage costs – software licenses can sometimes be prohibitively expensive. At one of the companies I worked at, one of our major line items was the software license fee for a particular technology, which cost us hundreds of thousands of dollars every year.
Now that we’ve analyzed the reasons for why switching technologies may make sense, let’s dive into how to make such a decision.
Selection Framework
When we talk about selecting new technologies, we should treat it like any other decision (e.g. adding a new feature to an existing product, changing careers, etc.).
We should always consider the status quo as a viable candidate.
In other words, sometimes the best path forward is to take no action, because the existing technology already best solves your needs.
You should never change technologies just because others tell you to. Change for its own sake can be counterproductive – you never want to be in a position where you’ve switched to a worse technology.
As a product manager, your job is to make decisions that resolve pain and provide value. Selecting new technologies is no different. Your first step is to identify the pain points of your . Treat your organization as your customer or end user.
When interviewing and documenting pain points, use two separate but related lines of inquiry. First, discuss the current technology. What pain is the current technology causing? For example, it may be hard for new users to understand how the technology works.
Just as importantly, what pain is the current technology already solving? That is, the organization picked this technology in the past to solve some set of pain points. What are those pains, and are they still relevant?
For your second line of inquiry, ask your stakeholder for their vision of an ideal world. In a perfect world, how would technology enable them to succeed? What sort of pains do they want a new solution to solve?
Don’t worry about the feasibility of your stakeholders’ requests. When you conduct customer research, your goal is to uncover underlying pain.
As you document these pain points, track which stakeholders mention which pain points, and how acutely they feel the pain.
Do not forget that you and your team are stakeholders as well. Ask your teammates the same questions as the above. Then, ask yourself the same questions. Because you and your team are the closest to the tech stack, it is absolutely critical that your perspectives are captured as well.
Comparative Technology Analysis
Next, create a matrix or spreadsheet. You’ll use this to analyze the pros and cons of each technology. I’ve placed an illustrative screenshot here
Here’s a link to a generic Google Sheet template that you can use. You can copy it by clicking on File in the menu bar, then clicking on “Make a copy…” (if the option is grayed out, make sure that you’re logged into your Google account).
Let’s walk through this comparative analysis together. Place each pain point that you collected in a row of its own. Write down every pain that you’ve heard, and assign some quantitative collective measure for level of pain.
Use a column for every technology that you’re assessing, including your current one.
Where the “pain” row and the “technology” column intersect, write down the feature(s) of the technology that solve for the pain, as well as a measurement for how well the pain is solved. You can use something like high / / low, or full / partial / none, or a numeric scale.
Most critically, do not include any features that do not solve any of the gathered pain points.
I’ve seen too many organizations select a technology just because it had lots of features, without critically assessing whether these features actually solved relevant pain points. Such a decision usually leads to poor results.
Some may feel uncomfortable with this exercise because it is not data-driven, as organizational pain is highly qualitative instead of quantitative.
I’ll be the first to acknowledge that product management is both an art and a science – and selecting new technologies is very much an art, not a science.
Still, by using a rigorous qualitative framework, you will dramatically reduce the uncertainty associated with such a critical decision.
After you’ve completed your evaluation from a pain point perspective, add in at least one more row to describe costs. Remember to account for hiring and onboarding costs, maintenance and integration costs, and licensing and usage costs. You can either bucket them all together, or break each one out.
Now, review your document and rank-order the various solutions based on your assessment. This review will guide the next phase of your selection process.
Organizational Buy-In
Your decision to select a new technology impacts your entire organization. Therefore, you must gain the confidence, trust, and backing of stakeholders across the .
To begin, review your document with stakeholders individually. Talk them through the analysis and provide your perspective, then ask whether they agree with your ranking.
Based on their input, decide whether you should tweak any of the assessments you’ve made. Iterate until you feel comfortable advocating for any of your stakeholders in front of any of your other stakeholders.
Then, gather your stakeholders and collectively inform them about your decision. Solicit any new objections that have not yet been covered, and address them as a team. Your goal for this meeting is to get unanimous commitment across your organization.
If you don’t, you’ll find that some departments or teams will passively or actively sabotage your efforts to implement the new technology – which we’ll discuss in our next article.
Meanwhile, you can join the PMHQ community to keep up to date.
Summary
Selecting new technologies is one of the most complex but impactful decisions that a product manager can make.
To succeed, treat the initiative just like any other product decision.
Conduct customer research to discover pain, assess the status quo against known alternatives, weigh tradeoffs, and get buy-in across the organization. By doing so, you’ve built up a strong foundation for success.
In our next article, we’ll discuss how to use this strong foundation to successfully implement your selected technology across the organization.
Additional Resources
For more information, check out the following articles! Note that most of them are written for Chief Technology Officers (CTOs) or developers, but that they provide helpful guidance and perspectives:
- Choosing, Keeping & Refactoring a Successful Startup’s Tech Stack (Snipcart)
- Seven Questions To Ask Before Choosing Your Technology Stack (Forbes, 2016)
- How to Choose Your Tech Stack (Silicon Valley Software Group, 2017)
- How To Choose The Right Tech Stack For Your App (QuickLeft, 2016)
Have thoughts that you’d like to contribute around selecting new technologies? Chat with other product managers around the world in our PMHQ Community!
