Abhishek Dwivedi is Director of Product Management at Issuu, a digital publishing platform that transforms PDFs and documents into dynamic marketing assets. He started his career as an engineer at Convergys and DXC Technology before joining HCL Technologies as a technical product manager. From there, Abhishek got his MBA and interned in the product management function at eBay. Prior to Issuu, he led product initiatives at Blacklane, a premium ride-hailing company connecting users with professional chauffeurs.
In our conversation, Abhishek emphasizes the importance of adapting frameworks to business context rather than applying them rigidly. He discusses how his engineering background prepared him to leverage root cause analysis in product management, as well as how AI creates more time during the week to spend on the field, focused on the user experience.
As I moved from an engineering role toward product, the most challenging aspect was the mindset shift. As an engineer, you’re almost always focused on the solution. The problem’s already there and you’re trying to understand the best way to solve it with your current tech stack. Your mind immediately jumps to whether something is possible or not. But, when you work in product, your job is not to find a solution, it’s more about constructing the right problem. That becomes essential, and it’s easier said than done.
I really like TSMC’s founder Morris Chang’s take on this. He says that without strategy, execution is aimless and without execution, strategy is useless. Technical execution is also important, but nothing makes sense if you are sailing in the wrong direction.
As an engineer, you go through 2–4 years of education and, at that point, you’ve already developed a critical thinking mindset. As an engineer, when something goes wrong, you have to do a root cause analysis and dig into things to find out why they happened. What will the team do in the future to make sure it doesn’t happen again? This skill is directly transferable to the product role. In product, you’re not into the solution space anymore — you’re in the problem space. But again, finding the right problem is not that easy.
It’s not as simple as someone saying, “If I had a button on the right side, I would just click it and get what I want.” That’s not what they’re looking for. If that were true, every app or website would be a bunch of buttons. With root cause analysis, you draw back to one simple problem statement. I’m particularly fond of the Five Whys framework to get down to this root. That’s what you have to get to solve something from the fundamental level, which will eventually deliver the right value to the customer. Getting into the five whys and the depth of the problem is very transferable from engineering to product.
I rank communication as the most important skill for this, and in product, it’s more critical than any other department. Why? Because product sits at the intersection of different departments. If you’re not able to articulate things and synthesize the right information, then it will inevitably have an impact on the product that you’re building.
You’re talking to designers, engineers, and users, and you have to get to the crux of everything while also being able to explain it simply to management for buy-in. And if you think about it from the perspective of what you’re doing and who you’re communicating with, it’s all individuals and regular people through the exchange of words as communication.
It’s important to remember that every person that you’re interacting with has a certain mindset. With that said, you have to tailor your communication with respect to who you are talking to. At a company level, sometimes you’re addressing a town hall. There, you can be high-level and showcase the vision, but when you’re talking to a team about translating that vision into action, you cannot be high-level. With them, you need to get down to fundamentals.
It’s all about understanding and communicating that we are all sailing in the same boat, but we have to go in the same direction. How do we align KPIs and the plan around that to build off each other?
Whether you’re dealing with your team or stakeholders, there will be some sort of negotiation at every moment. Stakeholders often have 20 things that they want you to do or push within the roadmap. How do you negotiate around that? What are the most important things? How can you say no or push back so that they accept it and also make sense of your reasoning?
It takes a little bit of understanding of all the personalities you’re working with, as well as doing the hard work to ensure your written and verbal communication is crisp. Personally, I’m not fond of long documentation. Having said that, they are essential at points when you need technical details and architecture. But if you cannot communicate the crux of things in a one-pager, then what are you doing? Why are you doing it? Why is it important for the company? If you can’t answer that, you need to sit down and write until you can do that within one page.
I have a love-hate relationship with frameworks. As I mentioned, I love simple frameworks — the “hate” aspect comes in when people use frameworks too rigidly because people sometimes want to hide behind them. You need to understand what makes sense in your specific scenario, in the context of your company and its stage, and the people within it. If you are in an early stage, then everything is focused on discovery. You’re trying to figure out what the right things to do and build are.
I already talked about the Five Whys, but I also like the Jobs-to-be-Done framework. With that said, if you get too deep into it, it can become an extensive process. But, the crux there is the jobs to be done. You try to understand why a user would buy your product and there are certain sides to it, there’s some functional value that your product delivers. There’s also some social and emotional side of the value that your product delivers. These are the more fundamental things that you should get into to differentiate your products.
There’s a famous growth framework called AARRR, which stands for acquisition, activation, retention, and referral revenue. A lot of companies use it and often structure teams around it. We used a similar thing, but we structured the team around the ethos of it.
So, we had an acquisition team that would work with marketing to own and be responsible for just acquisition. They’d monitor that and have their own KPIs. Then, we had a core team for activation and retention. They would focus on those two lines of the business and have their own KPIs. Lastly, for referral and revenue, we structured a monetization team.
It follows the same AARRR model in a way, but we optimized it based on our needs because, specifically during the last couple of years, we’ve been highly focused on monetization. This way, we could target people around that topic, which worked well for us. We recently went through an acquisition as a result of our last three years’ worth of monetization efforts.
When you’re a younger company, as you grow frameworks or processes, you’re often still exploring and trying to find that product-market fit. You have not created a ton of value yet. You’re still in this process of hunting for value, and at that point in time, you don’t need as many processes in place because there’s not as much value that could be destroyed. Often, processes slow you down, so when you’re a young company, you have to be quick and frugal to find your product-market fit.
As you grow bigger, that’s when you really need processes — a lot of value has been created and you don’t want to do anything reckless that would destroy the value. We saw what happened with CrowdStrike when the wrong code was pushed into production. Half of the flights around the world stopped because of that small bug. That’s the transition.
After you build and demonstrate value, you need all those processes so that nothing can destroy it in a split second. As you grow initially, yes, try to be quick and get as many things as you can to ship to the market. Then, once you have that muscle built, you get to the stage where you want to focus on the right things to ship.
In this world of AI now, you can have AI as a great sparring partner, such as ChatGPT or Claude. Earlier, you had to find the right person to talk to or exchange ideas. Now, you can talk to these AI tools, which can help you tailor your tools based on your specific needs. With AI, you can feed it context about your organization and the types of constraints you’re dealing with. AI can then tell you the tools that can help you adapt the framework to your needs.
Also, real product management doesn’t happen at the desk — it happens where your users and stakeholders are. That’s where the problem is, and you have to get to the root of the problem. You need to invest time there. Yet, there is a lot of overhead in product management, which includes tasks like documentation and writing. AI capabilities have reduced the time for this sort of work significantly.
AI and other technologies can change your time and role significantly. You can really help yourself if you become accustomed to new tools because, for example, I can now handle two or three teams at once, whereas in the past, that wouldn’t have been possible due to overhead work. With tools like AI, I can automate my workflows. I can set prompts and define templates to reduce my time spent on these tasks from 60 percent to only 10 percent. With the time that I’ve saved, I can spend it in the field understanding the business, market, users, and more.
Today’s college students are growing up with AI tools as an integral part of their workflow. Of course, business acumen remains crucial, but mid-career professionals will need to invest significantly to keep pace with their younger colleagues who are native users of AI technology. This shift is particularly evident in product management.
The current debate about AI replacing jobs mirrors similar discussions during the early days of computing. Like previous technological revolutions, AI won’t eliminate roles — instead, it will transform how we work. Each function will adapt and leverage AI in unique ways, creating new opportunities while evolving existing ones.
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.
Want to get sent new PM Leadership Spotlights when they come out?
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
