There is this trade off between: build the right thing / build the thing fast / build the thing right. For me this is right now very difficult. Stakeholders mainly focus on build the thing fast with extreme lean mindset actually sometimes leading to a lot of technical debt if their advice is followed. The end users mainly give me an idea what the right thing is to build but have often their wish list is too long and unrealistic. Engineers generally want to build the thing right and are the extreme opposite of lean. What are your strategies for balancing all these? I currently see as our team would not fall into the empowered category that we kind of need to play it safe and need to strongly go lean. But how do you ensure that you do not create too much debt by working that way?
Customer comes before ANYONE during interviews and surveys . I then involve my engineers early on in defining what to build. I make the shots but they are part of the convo . Other stakeholders won’t argue against a data backed direction and you use them/ they use you as needed along the way. This is my way.
I always plan an MVP to test first with most new development ideas, whether they come from customers or stakeholders. We build fast, get it live and test for the one metric we think it will affect. If it succeeded, we commit to rolling it out in a sustainable way (considering other metrics, and ensuring it’s built with the least amount of tech debt possible). I got stakeholders on board with this so they know the process, and it keeps the product lean (no features unless they have proven value), while keeping stakeholders happy that their request has been worked on. This short term approach also helps developers care less about fast work in the MVP stage.
As a product manager, you need to figure out what is the most valuable from the long wish list of customers and stakeholders, including stuff no one has requested but might be the most important to deliver.
Then you need to convince both external stakeholders and the engineers that this is the right thing to build. You might want to have data, results of experiments, customer interviews, etc to back up that path, combined with your ability to present things on a clear way.
For speed of building, your engineers should be able to give you different options with different levels of technical debt. This is a delicate, critical, push-pull “dance” between you and the engineers, often works much better if there is mutual trust. Your engineers must be able to reason and describe the business impact of the options. Whichever option you pick from the list they provide, you need to defend the selected item towards stakeholders (for that you need to understand the basics of that choice and the business impact) and towards the devs (for that you must be able to understand and explain the business needs).
There will come payback times for the technical debt you picked (outages, slow downs in dev speed, etc), be prepared to defend the team from consequences - for example when making a feature, explain the tech debt consequences to stakeholders. Possibly need to explain it several times and also in writing. If you do so chances that stakeholders remember they agreed to this will increase and it will be easier to make them accept the situation.
The actual balance point will depend on the company and the product. For a startup, more tech debt will be necessary to find product-market fit fast enough. While for a mature product with a lot of customers, outages have bigger impact and lower level of tech debt is desirable. Things might also change with time - after a series of outages, tech debt tasks are not only accepted more but also can be pushed by stakeholders.