Being truly agile
There’s a lot of confusion around the word "agile." It doesn’t mean “switch context very often.” It means "learn fast".
Product development isn’t about sticking to frameworks and methodologies. It’s about using the best methodology to achieve customer and business goals as quickly as possible.
As a business, you have your business goals and strategy, and ideally, you achieve those through your product by creating value for your customers. The faster and higher you increment the value for your customers, the faster you grow. Therefore, you need to spend the least amount of time off-track, working on something that does not increase the value.
I could go in-depth for every track in the high-level scheme below, but before you try reading it like a waterfall, keep in mind that this is happening continuously, in parallel, not in sequence.
The job isn’t done when you deploy something into production; the job is done when the goal is hit. You don’t learn just from releasing an update, as that’s too costly and too slow. Instead, you aim to learn as much as you can in discovery by conducting research activities such as customer interviews and multiple experiments within a sprint. Without writing code. And if you must write code, you hash together something quick&dirty, because there's a high chance it will be thrown away.
You try to gain as many learnings as you possibly can in the shortest amount of time. Learnings that tell you that you are wrong are even more important than learnings that tell you that you are right.
Product strategy is essentially a set of objectives you want to achieve through your product. You need to find evidence in your product telemetry that the problem to be solved exists; hence the opportunity exists. That’s your baseline. Your objective dictates what the goal is and where you want to shift a given set of metrics from the baseline.
If you are 100% sure what's the solution, build it. But if you face an unknown, you need to conduct discovery. You need to form hypotheses, verify them, reject them, and run discovery to understand value, usability, feasibility, and viability. Once you compare and contrast possible solutions, you choose one to bet on.
You build the potential solution not to verify a hypothesis but because you verified it in your discovery. You release at least once a sprint to prevent big changes - to fix bugs faster, to learn faster, to bring users on the journey of changes. However, it may still happen that reality will pan out a bit differently, and you need to take more learnings once you release.
A release is much more than just a deployment. You need to take the updated product to market. The amount of related work depends on the granularity of the update. It ranges from driving activation and adoption to selling a new product with new messaging, positioning, and pricing; and of course, value proposition, because if you still remember, that’s why you started developing the product in the first place.
