Tech Mastery Part 2: Adopting Your Product Stack

We’re back! You’re reading Part 2 of Tech Mastery, where we’ll be teaching you how to choose the right tools for your product stack as well as how to help your teams to properly adopt them. We’ll also help you ask for more budget, and show you how to get started on our brand new Learning Path!

Catch up with Part 1 of Tool Mastery right here!

Choosing The Right Products

Now we come to the main meal…choosing the right tools! This is absolutely key. If you don’t get this part right, it doesn’t matter how well you do the rest of it. Sometimes, a choice is very clear. You’ve got two options for which design tool to use, for example, and one of them is clearly superior for your needs. Easy.

Sometimes it’s not so clear. You’ve got at least twenty viable options, all with different features and capabilities (and price tags) you’ll need to do a bit more work to make a selection.

Start by performing an internal audit of your current stack, and identify its main weaknesses and strengths. You should be able to easily identify what things the team can’t do without, and what needs improvement. To do this, you could send out a quick employee survey, asking teams to identify their pain points with your current stack, or things that are missing.

When conducting your internal audit, don’t just look for problems, but look for delight as well. Someone could tell you two problems they have with Figma, for example, but they might also be able to tell you fifty things they love about it if you were to ask. Make sure not to axe something that people love to use just because you focused solely on pain points.

If you’re looking for a template for your internal tech stack audit, we’ve made one for you right here!

Quick tips for choosing the right products

  1. Research the product and it’s ‘health’. For your most critical tools, you need to ensure that you’re not at risk of disruption to service. Is the tool known for having great customer support should things go wrong? What are the customer opinions from others who have similar needs to yours? Is it at risk of shutting down/being acquired any time soon? These are important questions to ask.
  2. Demo before you buy. Try to get your hands on a free demo (most SaaS companies provide this as an option by default, but if you can’t find it then get in touch with a rep to provide you with one. Get a demo of a tool before you use it, and try to get as many hands on that demo as possible.
  3. Harness the power of negotiation. There’s often no harm in the art of the haggle. When products don’t come with an upfront subscription cost, and you need to talk to a rep to start the onboarding process, you have an opportunity to negotiate. You’ll be in an especially good position if you need a large number of user log-ins, or are buying a tool for a large organization.
  4. Treat your stack like a product. Too often, designing a product stack is treated as one task on the to-do list, and not as an entire project. Building internal products is treated almost the same way as building a product for external end-users. And the same treatment should be afforded to your product stack. Treat it like a product and give it the time and people-power it deserves.
  5. Consider the data literacy/tech prowess of your team. There’s no point investing in a tool if only 5% of the people who need it are trained to use it. If you need to invest in more complex software, factor in the cost of employee training.
  6. Consider your ecosystems. Buying a slightly less impressive tool that integrates with more of the others in your stack may be a better idea than getting something powerful that operates in isolation.

Where to find tools

Search results will get you what you need, but they’re not much help when it comes to choosing the best tool. You need recommendations, demos, and hand-picked lists. We can help with that!

  1. Check out Productverse, our collection of favorite products and platforms.
  2. Check out The Proddy Awards, the annual awards for the best tools in the tech world!

Stack vs suite

Another consideration is whether a product stack or a suite will be best suited for your needs. While a stack is composed of different products and services linked together by integrations, a suite is an all-in-one solution offered by a single provider. It’s like having an unfurnished house – do you trawl all of the different furniture shops and put together a nice-looking interior yourself, taking measurements and making sure it all fits together? Or do you hand yourself over to a single store and have someone from their team put it all together for you?

It’s often not as simple as choosing one or the other, and it may not be clear whether a suite or a stack are the best solution for your company.

Both options offer pros and cons:


✅ More customization options

✅ Allow you to be more flexible should your tech needs change

❌ Too many integrations can be difficult to manage

❌ Run the risk of data islands


✅ Becoming more and more stack-friendly

✅ Simpler to choose one suite provider than dozens of individual SaaS tools

❌ Less options for customization

❌ Leave you dependent on a single vendor

If you’re struggling to come up with a stack of individual SaaS tools that works for your needs, or you’ve found that managing the many integrations required to build a working ecosystem takes up too much bandwidth, consider a suite as an alternative. But treat it the way you would any other SaaS tool choice. Consider the pros and cons of the vendor, researching things like customer service scores and the overall health of the company. Talk to reps, ask for demos, and make sure it’s a choice that you, and your teams, are happy with.

The benefits of low-code/no-code tools

Low code and no code tools have swept the tech world for several reasons. We’ll let Chakkaradeep Chandran, Senior Product Manager at Microsoft explain why…

I value two things when it comes to low-code tools: ease of use, breaking down complex things so I as a user need not worry about things like database scalability, authentication, performance etc. And great-looking outputs.

Low code tools aren’t meant to be a replacement for engineers or data professionals, who will always be inseparable from the process of building great digital products. What low code tools do is empower non-tech teams to do more for themselves, freeing up tech teams’ time for more important work.

Some low code tools are not as powerful as their less user-friendly counterparts, so they’re not quite a one-size-fits-all solution. This is why it’s so essential to listen to your teams and understand their needs before you buy a new tool.

Check out our guide on How No Code Tools Empower Product Teams to learn more.

Build vs Buy

It’s not uncommon for organizations to buy the products and solutions that they’ll use internally rather than spend their engineers’ time building it themselves. The build vs buy debate is one that almost every product team will have to face eventually.

A good piece of advice when thinking about whether to build or buy a particular product, is to ask yourself ‘is this part of our company’s core competence?’ If the answer is anything other than yes, start looking for solutions to buy.

Of course, that’s a very simple rule of thumb. Each company will need to weigh up the pros and cons of building vs buying a solution. When thinking about this debate in your organization, consider:

  • The effect building will have on your team’s capacity to build other products and applications
  • Security benefits and risks
  • Integrations
  • Long-term viability

Check out: The Great Build vs. Buy Debate: Why You Should Buy

A template for requesting products

Once you’ve decided on the products you want, chances are you’ll need approval from the people in charge of the purse strings. That’s easier to do if there’s already a formal process for requesting new tech in place. In case there isn’t, here’s a quick and easy template you can use to get you started.

Part 3: Helping Your Teams Adopt a Product Stack

Once you’ve got the go-ahead to purchase and implement your product stack, it’s time to make sure that your entire team takes to it. If people don’t feel comfortable with the technology you’ve given them it’ll slow them down, create roadblocks in the day to day, and they may even avoid it completely.

There are several common mistakes leaders make in introducing a new product stack to their teams. Let’s dive into them now, and then we’ll tell you some top tips for getting it right…

Mistakes to avoid

It’s a surprisingly common mistake to collect as many products as possible, but if the pieces don’t slot together perfectly you can actually find yourself in a mess of notifications and copy-pasting from one whiteboard tool to the next.

The last thing you want is for your teams to be drowning in products! Having too many products that don’t connect with each other can lead to data islands, which makes it pretty hard to get useful insights from your data. And data without insights is just a string of numbers.

Not only does it lead to data islands, it also means you’re unnecessarily blowing your budget. The price tag at the end of the day for having lots of lower-cost products instead of investing in an expensive one is often surprisingly large. You also waste resources and time by having the team switch from tool to tool, instead of having one thing that does it all.

It’s good to try a few freemium products and to make the most of free trials, especially if you’re a bootstrapped operation. But don’t do your teams a disservice by being too stingy. Not only does this not help them to build products at a decent speed, it also sends the message that you expect them to work at a disadvantage. If you wouldn’t ask a chef to prepare a meal without sharp knives, don’t ask your teams to build a product without the right tools!

When it comes to adoption, the biggest mistake you can make is to be a dictator. Let’s say you’re choosing your new design tool. You used Sketch at your last job and prefer it to Figma, which your teams say they prefer. Even if you’re the decision maker, you don’t just get to pick your favorite tool and roll with it. Your tools are supposed to work for your teams, not the other way around.

Top tips for adopting a product stack

When helping your teams to adopt a new product stack, there are a few key things you can do to move the process forward and have everyone feeling comfortable with their new toolkit.

Firstly, try to make sure you’re only introducing a few products at a time. When you’re building an ecosystem, it’s rarely possible to introduce one new tool in isolation. To understand how it works, teams need to see how it works and integrates with other parts of the stack. Try to break the stack down into as small chunks as possible, and introduce your teams to a couple of products at a time.

Another key to successfully adopting a product stack is to be open with your timeline. Chances are your teams are eagerly awaiting their new tool ecosystem. If they’ve been without that perfect workflow, and they’ve put in their requests for new products, they’ll appreciate being kept updated on when they can expect to get them.

Once the process is underway, it’s important to be open to feedback. If you’ve done your job right, then your teams should love their new product stack. And there’s bound to be some growing pains where you’ll be configuring plugins and trying to figure out why a particular integration isn’t working. You’ll have to filter out growing pains from genuine criticism.

When adopting a new product stack, some questions and roadblocks are bound to appear, and some may be down to the tool itself. This is why it’s so important to know exactly who your POC is at each supplier. For example, who do you contact when something breaks, or what happens if an important integration isn’t working the way it’s supposed to? Clearly communicate who is contactable for what, and share that with your teams. This is especially important for distributed teams in different timezones. If something breaks at 3am when you’re fast asleep, your teammates on the other side of the planet know who can help.

Lastly, be patient. Handing your teams an entirely new set of products is basically like asking them to re-learn how to do their jobs. Make it as easy as possible for them by recording videos of how to perform tasks, like ‘how to leave a request for the design team’ or ‘how to run a retrospective.’ These are things that teams can use to learn their new stack and also to keep refreshing their memories until it feels like second nature.

Ready to learn more?

Building a product stack isn’t easy…we know! And this has been a pretty hefty article to digest in one go. So why not pick up our latest Learning Path, Choosing Your Product Tech Stack. You’ll get actionable advice from top-tier Product Managers who are experts at empowering their teams with the right tools to build great products.

Check it out right here!

Enjoyed the article? You may like this too: