When working as an engineer, product owner, tester, or any role you have within an organization. Having a flow of work is outstanding. It gives a thrill of progress, and everything that blocks is an absolute pain. Sadly, the reality is different. Most organizations have a mediocre flow of work where it slowed down or even grounded to a halt.
If you work as an engineer and you don’t release to production at least daily, you lack proper flow of work, and something trapped you in an unnecessary process. This could be anything from code reviews, waiting for QA people, Release Managers, a Random Manager to approve, or just waiting for a colleague. If this is the case, reevaluate your process! The longer it takes for you to get to production, the longer your customer has to wait for something useful and for you to learn and improve.
Even if you can push to production multiple times a day, without product discovery, how would you know you push the right thing?
Product discovery is hard! Often, I see product teams stuck in a feature factory cycle. I get it, stakeholders push product managers to deliver some sort of feature as promised to customers. This stakeholder push translates into an engineering push to deliver more features in a shorter amount of time. This ends up in an unstructured and hard-to-maintain product. If the business stakeholders are the ones that push the product, they are the ones defining the product strategy. As Marty Cagan said:
“We need a product that our customers love, yet also works for our business.”[1]
That promised feature doesn't generate a product that customers love, famously mentioned by henry ford:
"If I had asked people what they wanted, they would have said faster horses.”
Instead of fully focussing on feature requests from stakeholders, figure out what the problem is your team needs to solve. Correlating stakeholders' feature requests towards the real problem might shed some light on what customers need.
Like Melissa Perri said in her book, escaping the build trap:
“When companies do not understand their customers’ or users’ problems well, they cannot possibly define value for them. Instead of doing the work to learn this information about customers, they create a proxy that is easy to measure. “Value” becomes the quantity of features that are delivered, and, as a result, the number of features shipped becomes the primary metric of success.”[2]
As long product managers do not have a clear picture of what the problem is, it is significantly harder to say no to a stakeholder. Or maybe the problems are obvious, but there are just too many of them. These are signs you might need to take time to define a product vision.
When teams lack the ability to supply a proper vision, the team will run in circles on daily issues. It is helpful for teams to know the future you want your product to fulfill and why. However, a vision is not enough when you need guidance to build what how and for who, this is where a mission comes in.
A mission statement should clarify the who what and how. The mission should give you guidelines on how to arrive at your vision. It should guide the product team on what functionality to build and when to say no. If a request from a stakeholder does not fit your vision or mission, you should not do it.
Once great product discovery and delivery are in place, the team can move and get a flow of work! Product managers figure out the strategy. With a place to go, engineers can attune the product to the strategy. Together learn from released functionality and figure out if the team is still moving in the right direction.
Once you have worked in such a company, and you are moving forward towards the goal, you feel the enthusiasm. The product makes sense; it solves something and is used every day while getting better and better.