by Jenny Boronyak | Feb 11, 2015 | ITIL and Service Design, Product Development |
When we’re designing new solutions for our customers, it can be easy to get caught up in the products and features we create and neglect to ensure that what we are building actually ends up delivering value to our customers. It can be challenging to acquire the necessary deep understanding of what our customers consider valuable. Value Proposition Design, described in the book of the same name written by Alexander Osterwalder, et. al., is great for organizations who are overwhelmed by the task of creating value for customers, a task which can be incredibly difficult without the proper guidance. According to the authors of this useful method, value proposition design helps people “successfully understand the patterns of value creation” by making them easily visible. Following this method, we don’t just end up designing products, but rather entire value propositions that directly effectively target our customers’ jobs, pains, and gains. In the book, the authors describe tools that can be used to continuously create and improve value propositions that meet customer expectations. One of the most useful tools that can be applied to discover value propositions is the Value Proposition Canvas. The Value Proposition Canvas is made up of two sides: Customer Profile—This part clarifies our customer understanding Value Map—This part describes how we intend to create value for our customer The goal is to achieve “Fit” between the two sides of the canvas by ensuring one agrees with the other. The Customer Profile, or Customer Segment Profile, describes a specific customer segment by breaking it down into customer jobs, pains, and gains. Identify these three items to create a...
by Jenny Boronyak | Dec 10, 2014 | Agile, Business Analysis, Collaboration, Product Development, Project Management |
A clearly-defined Definition of Done is absolutely essential to agile software development. At the end of every sprint or increment, software is demonstrated to the product owner and relevant stakeholders to make sure that the increment is done. But too often, we end up accepting the work completed during the increment even though it isn’t truly done yet – “DONE-done,” as we call it at Enfocus Solutions. A Definition of Done creates a shared understanding of what it means to be finished. According to AgileAlliance.org, the Definition of Done is a list of criteria that must be met before a product increment is considered “Done.” The Definition of Done is also an expression of the team’s quality standards. A more precise Definition of Done is often associated with the delivery of higher quality solutions. Generally, the team will increase their velocity as their Definition of Done gets refined, because they will improve release planning and spend less time fixing old problems. The most important function of the Definition of Done is that it provides a clear description of what it means for an increment to be done and ready to be implemented. It helps us avoid misunderstandings and miscommunications, and makes sure that there’s transparency around what the team is doing during the sprint. It is difficult to pin down a Definition of Done that suits all circumstances. Each organization needs to define their own definition; the checklist found in this pocket guide is meant to serve as a guideline for building your own Definition of Done for an iteration. Here’s a couple tips for dealing with the Definition...
by Jenny Boronyak | Dec 3, 2014 | Agile, Product Development, Project Management |
At Enfocus Solutions, we’ve adopted much of the Scaled Agile Framework®, the premiere scaling framework for scaling agile developed by Dean Leffingwell and Scaled Agile, Inc. One of the many aspects of the framework that makes it such a useful tool is Leffingwell’s concept of Inspect and Adapt Workshops. Building on one of the principles taken from the Agile Manifesto that, “at regular intervals, the team reflects on how to become more effective,” SAFe® incorporates the Inspect and Adapt (I&A) workshop at the end of a release or Program Increment (PI). According to SAFe®, “I&A is to a Release Train what the sprint demo and retrospective are to a team—a regular, programmatic, time to reflect, problem solve, and take on improvement actions [to] identify actions needed to increase the velocity, quality and reliability of the next increment.” When discussing the Inspect and Adapt workshop, the Scaled Agile Framework® describes I&A activities occurring only on the program level. However, at Enfocus Solutions, we like to take it a step further and carry out Inspect and Adapt activities at every level: portfolio, program, and team. This way, we review the solution constantly, making it more likely that we catch problems and issues as they happen, instead of during a demo with a stakeholder. At each level in the organization, there are activities that can be performed that will help ensure your teams are continuously inspecting and adapting, not just during program level events: Portfolio—A formal Performance Evaluation (or, inspection) should take place to ensure the Program Portfolio achieves the desired performance by measuring business outcomes against predetermined KPIs. There may be...
by Enfocus Solutions | Apr 21, 2014 | Collaboration, Product Development, Uncategorized |
For Part 1: Easy to Talk About, Much Harder to Achieve, read previous blog post For Part 2: Working Together through Product Discovery, read previous blog post In the last blog post we talked about the importance and the opportunities for collaborating during the product discovery phase of the product development lifecycle. In today’s blog post, we take a look at collaboration through the product delivery phase of the product development lifecycle. Collaboration during Product Delivery The second track in the dual track agile approach to product development is the product delivery track. Once a feature has made it onto the product delivery track, it will have been validated for viability and an understanding that the right feature has been defined — but now needs to be built correctly. Easy right? Not without collaboration and validation from your development team, your users, your marketing ream, your design team … well, you get the picture. Just the same as product disovery requires a collaborative validation effort to be successful, so does product delivery. The difference in the product delivery phase is that the focus becomes less of ‘are we building the right product’ — and more of ‘are we building the product right?’ This means the focus shifts towards ensuring a product will be adopted — in other words, the focus is on the usability of a product and ensuring the features that are developed, are developed in such a way that they will actually be used. User adoption is driven by understanding what the user needs Once a product reaches the delivery phase, we know that it is the right product, but that...
by Enfocus Solutions | Apr 1, 2014 | Collaboration, Product Development, Uncategorized |
For Part 1: Easy to Talk About, Much Harder to Achieve, read previous blog post The question of when teams need to collaborate in the product development lifecycle has an easy answer: always. But, there are key activities that take place within a product development lifecycle where collaboration is absolutely necessary. Collaboration through Product Discovery and Product Delivery There is an emerging concept in product management called dual-track agile that essentially looks at product development as two tracks: the product discovery track, and the product delivery track. On the product discovery track, teams collaborate to understand what the right product is to build. On the product delivery track, teams collaborate to make sure the product is built right. (Source: Jeff Patton, www.agileproductdesign.com) Both tracks require a foundation of collaboration and validation in order to be successful. In today’s blog post we’re going to talk about the importance of collaboration through the product discovery phase of product development—when teams are trying to figure out ‘what’ actually needs to be built in order to be of value to the market. Traditionally, in the product development lifecycle the validation of a product doesn’t tend to happen until after the launch of a product or during the validation of a developed prototype. Usually by that time, a significant amount time and money has already been spent on defining and developing the product to some degree—without completely validating that the product will meet a market need. On the product discovery track of the dual track agile approach, the focus is on validation, validation, and validation. Validation that the right problem has been identified, validation that...
by Enfocus Solutions | Mar 27, 2014 | Collaboration, Product Development, Uncategorized |
We’ve all heard about collaboration, talked about collaboration, and probably even agreed that collaboration is really really really important—problem is, it seems much easier to talk about than to actually achieve. One of the key roles a product manager can play in any organization is to bring people together—to bring customers and users together to understand what their problems are and how to best solve them, to bring internal stakeholders together to understand what products will best serve the organization, and to bring the individuals of a product team together to work synchronously towards launching a valuable product that will delight their market and upset their competitors. But the fact is, it’s really challenging to get people harmoniously working together—and just as hard to keep them doing so throughout the entire product development lifecycle. As humans, we are all inclined to fulfill our own needs first—but when it comes to collaboration, those inclinations need to be shifted towards each individual working to fulfill the needs of an entire team before their own. If you’re thinking it sounds like hard work then you’re right—fostering collaboration during the product development lifecycle is indeed hard work. But it’s hard work that pays off. It’s currently estimated that 70-90% of all new products fail. You wouldn’t be alone if your initial reaction to that number is ‘wow!’ It seems like too high of a number—and one that makes launching a new product seem like a pretty bleak undertaking. But if we look at the leading cause of failing products then we might see that there is hope for a solution: the number one...
