Have you ever stumbled upon any of the following?
If you connect to the above points, there is a high chance of a mismatched tech stack. This is painful, and replacing it on the way is beyond costly.
How do you define the right tech stack for your product?
Let me help you understand what a tech stack is, how to choose the right one, and how you, as a product manager, can influence that.
Jump ahead:
I’m pretty sure you’ve heard the term “tech stack” or “solution stack.” If you know that well, just skip this session. Otherwise, stick with me, and I will explain briefly.
The tech stack represents the technologies used behind the product. For example, take an online shop. When you disassemble it into parts, you’ll have (in summary):
The above represents just a small part of a system. The tech stack for that could be:
In practice, a technology stack will become more extensive than this one, but I imagine you get the point. The combination of potential technology is endless.
Context matters a lot. When you set this incorrectly, you’re doomed.
When I had my first startup experience, I failed to set the context right several times, and that caused significant waste. Let me share a little story with you.
We had created an internal solution to help customer service handle bookings. It was a simple application, but it lacked user management. A software engineer had to do it manually whenever we had to change roles or add or remove users. That was nonsense, and we had to change it.
I sat with the team and agreed on creating the user management feature. The team confidently said it would be no more than two weeks. I was okay with that. But two weeks later, I was informed they needed one more week. I was annoyed but didn’t challenge that, which I regret.
A week later, I got more excuses for another delay, then I had a serious conversation with the team, and it went like this:
David: “What’s going on?”
Dev: “We’re struggling with the scalability of our user management.”
David: “Scalability?”
Dev: “Yes. We’re building robust user management. We decided to replace our database with a non-relational one and implement microservices. We’ll be able to support thousands of parallel users. State of the art. Be calm. You’ll love it.”
David: “I see the problem. I set the wrong context. The application needs to support fewer than 100, if not 50, users in five years.”
Dev: “Wow. If only I had known that, it’d have been done in a day or two because I wouldn’t have changed our tech stack.”
The important lesson here is to set the context instead of telling software engineers what to deliver.
The wrong tech stack will get in the way of reaching goals.
The tech stack is the means; you need to know the end.
You might see many immature software engineers talking a lot about the tech stack without knowing the goals. I cannot emphasize the downsides of using the wrong tech stack enough.
Let’s clarify some aspects.
The CTO is accountable for technology-enabling business strategy. Although many CTOs may delegate this responsibility to teams, the accountability lies on the CTO’s shoulder.
Where do product managers fit in this equation? Remember, technology is the means, and the end is what product managers need to provide. In other words, the goal.
I call this setting the context, which can be easily misunderstood. I will do my best to clarify.
The common mistake is asking software engineers to deliver features. In this case, they lack the required information to choose the appropriate tech stack. Don’t do that.
Ensure the following aspects are clear to engineers before they write the first code line:
When you set the context right, choosing an appropriate tech stack becomes easier.
It’s fundamental to ensure engineers understand the context. A simple technique is asking them to explain to you in their own words. That allows you to correct misunderstandings.
Defining the tech stack isn’t a single-person decision. I’ve seen companies letting this entirely to the CTO. As a result, everything got super complex and slow.
When it comes to tech stack, you won’t find anything like one size fits all.
Collaboration is vital to define the most appropriate tech stack for your product. Set goals and work backward. Ask your tech people how best we reach these goals. The answer should be a fitting tech stack.
Another aspect is product managers running away from tech stack discussions. Many product managers ignore the tech stack, which I’d see as a mistake.
Great product managers understand how the dots are connected and continuously ask software engineers, “how does technology X help us reach goal B?” Such questions help engineers think about goals and reflect on the best technologies for these goals.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Following up with meeting minutes ensures alignment with stated values and holds individuals accountable for what was discussed.
Vanessa Davis, VP of Product Management at LegalShield, discusses how legal precedent directly challenges the notion of innovation.
Keep the lights on refers to everything that comes between your product and your customers receiving its promised value.
The stronger the habit, the more often users want to use your product and the lower the chance of them churning.