apm 6 1

Eric Ries in his book the Lean Startup said, what if we found ourselves building something that nobody wanted? In that case, would it matter if we built it on time and on budget? It's not just about creating a product that works. It's about creating a product that solves real problems for real people. Something people want out to ways of working, particularly through the role of the product owner and the concept of minimum viable products, or MVPs, they help us deal with this. Product ownership is focusing on building the right thing and bringing the customer into our development process. Now, the role of a product owner, well, it's essential. Regardless of whether you're using Scrum or Kanban or really any Agile approach to project management, their primary responsibility is being the voice of the customer, ensuring that the Agile team is working on the highest value items and product owners. They have several key responsibilities and it's important to note, like they don't work alone, they don't work in isolation. They collaborate with all kinds of stakeholders, people like business owners or compliance teams, of course, the end users and even the project management offices. And they use all of that information to make decisions that reflect the business needs. And one of the primary tools that the product owner has is the backlog. In Scrum, it might be called the product backlog, but you might also hear it refer as the team backlog. A backlog is a container for all the work items that the product owner wants the team to work on. It's important to understand that everything that the Agile team will work on, it has to be in the backlog. There's no sort of hidden work. I often say it this way. If it's in the backlog, we might do it. If it's not in the backlog, there's no chance we're doing it. So this would include bug fixes, new functionality. Those might be represented as like user stories, documentation updates, really any task the team needs to complete. The product owner's responsibility is to order these items, placing the most important ones at the top of the backlog and the least important ones towards the bottom. A healthy backlog, well, it's not static. It evolves over time as the product and market needs change. Effective prioritization is key to delivering maximum business benefit while potentially doing less overall work. Again, just because it's in the backlog doesn't mean we necessarily are going to do it. And this is where concepts like the minimum viable product or MVP come into play. Now, MVP is often misunderstood. It often gets described as the least amount of work we can do in a given time frame. Or it's everything we need to do our job, or everything the old system used to do. That's the minimum. But a more accurate definition is. In simpler terms. An MVP is the fastest, cheapest way to test a hypothesis for a new product or service. By focusing on an mvp, we're able to deliver value incrementally and to learn from real user feedback rather than sort of making assumptions about what users want. There's actually four main types of MVPs, each serving a specific purpose and validating different aspects of a product or a service. We have the wizard of Oz mvp. Now, in the wizard of Oz mvp, all or most of the technical sophistication that happens behind the curtain, well, that's just executed manually. This allows us to test the viability of a product before we invest heavily in technology. A classic example of this is in the early days of Zappos, the online shoe retailer. When Zappos first started the idea of buying shoes online, like, it just seemed crazy. How could people buy shoes without trying them on? Well, to test the hypothesis, Zappos created a basic e commerce website with pictures of shoes from local shoe stores. And when customers placed orders, Zappos employees would then manually go purchase the shoes from the shoe store and then ship them off to the customers. So this allowed Zappos to validate their business model without investing in inventory or complex logistics systems. Okay, next we have the Concierge mvp. In a Concierge mvp, a human manually helps users accomplish their goals as a means of validating whether there's a need for what you're offering. This type of mvp, it allows you to understand user needs deeply before building any technology. Now, a funny example of this, though not an actual mvp, comes from the TV show Seinfeld. Hello and welcome to Moviefog. If you know the name of the movie you'd like to see, press one. Okay, we've got the Landing Page mvp. A Landing Page MVP is just a simple webpage that defines your products, its benefits, and maybe offers users a call to action. This type of MVP is excellent for gauging initial interest in a product idea. And finally, we have the Email mvp. Now, an email MVP that just involves sending out a simple email blast that describes the product or service, and then as a call to action. We took a similar approach to this at Kairise. When we decided to build the class you're currently in, we didn't use email, but we used LinkedIn polls to gather information from my connections. These MVP approaches, they all share a common goal to validate assumptions and gather real user feedback with minimal investment. By using these strategies, product owners can assure they're building something users actually want and need. So by embracing these approaches, we can build products that truly meet customer needs while we're maximizing our efficiency and effectiveness. And as development teams.