Have you ever stumbled upon any of the following?
- Scaling up your audience becomes a hassle
- Adding functionalities to your product is a constant challenge
- Every small change takes significant time
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:
What’s a tech stack?
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):
- Frontend: what users interact with. It’s like the shop in itself
- Backend: what happens behind the curtains. The frontend (when done well) is just a layer and has no business logic because the back end handles all of that
- Search engine: whenever you search for a product, an engine optimizes the results to give you better options
- Database: the place where the data is stored. Imagine the following: the user goes to the shop (frontend), hits the Add to cart button (the backend handles the request), and then proceeds to check out (the database stores the information)
- Queue: an online shop has several requests at the same time, and it must handle them properly. For that, a queueing system is set
The above represents just a small part of a system. The tech stack for that could be:
- React.js, Golang, Searchanise, PostgreSQL, RabbitMQ
- Angular, C#, algolia, MongoDB, activeMQ
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.
The cost of a wrong tech stack
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.
Setting the ground for the right tech stack
The tech stack is the means; you need to know the end.
Learn more →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:
- Reach — how many users do you want to reach initially? Give a picture of the now and the future. Leaving this open will force engineers to make assumptions that may turn out wrong. Remember my example
- Quality aspects — be as precise as possible. I see many product managers using words like “fast,” “quick,” etc. Everyone has a different interpretation of fast or quick. Name it if you want the search to return results in a second. Don’t say you want the search to be fast
- Scalability — how do you expect the product or feature to grow? Hopefully, you’ve done your homework and can reply to this question quite well. It’s essential to ensure that engineers don’t focus on building a highly scalable solution first, but they know where you want to be. That allows them to make better-fitting calls
- Expectation — time matters. If you leave that out of the equation, you can be surprised by how complicated things will get. Make your expectations clear when you want the product in the users’ hands. If that’s unrealistic, exchange with engineers to find a reasonable time. The point is to talk about it instead of leaving it open
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.
Final thoughts
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.
Subscribe to our product management newsletter
Get articles like this to your inbox
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 generates product insights that lead to meaningful action
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 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.
