by Jenny Boronyak | Apr 23, 2015 | Collaboration, ITIL and Service Design |
“In this Age of the Customer, the only sustainable competitive advantage is knowledge of and engagement with customers.” – David M. Cooperstein, “Competitive Strategy In The Age Of The Customer,” October 10, 2013. According to Forrester Research, the Age of Information is over and we are now firmly in the Age of the Customer, a time when a strategic focus on the customer matters more than any other imperative. In two insightful reports, The CIO and CMO’s Blueprint For Strategy In The Age Of The Customer, Forrester Research lists the four key strategic imperatives that are necessary to establish a competitive advantage in today’s customer-driven marketplace. Every service organization should be following these four imperatives: Focus on the customer experience. In the Age of the Customer, if we’re not strategically focused on designing and continuously improving a valuable customer experience, it is impossible to compete with the top companies in the industry. With all of the digital technologies and disruptions, today’s customer is more empowered than ever. The only way we can anticipate the needs of today’s customer and develop valuable service experiences that excite and delight is to become “customer-obsessed.” The definition of being “customer-obsessed,” according to Forrester Research: “A customer-obsessed enterprise focuses its strategy, its energy, and its budget on processes that enhance knowledge of and engagement with customers and prioritizes these over maintaining traditional competitive barriers.” – Kyle McNabb and Josh Bernoff, “The CMO’s Blueprint For Strategy In The Age Of The Customer,” September 12, 2014. To become customer-obsessed and successfully create excellent customer experiences, we need to improve the way we design all aspects of...
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 Karl Wiegers | Nov 7, 2014 | Business Analysis, Collaboration |
The business requirements will help the business analyst identify potential user classes for the product. The objective of exploring user requirements is to understand what members of these user classes expect to be able to do with the product and how the product will let them achieve specific goals. The user requirements must align with the higher-level business goals captured in the business requirements. Some user goals might pertain to tasks the users must perform; use cases often are an effective way to record these tasks. Other user goals, though, might indicate the importance of specific nonfunctional requirements. Examples include the ability to complete a task within a certain length of time, and the ability to access a system remotely from a smart phone. Therefore, user requirements also encompass the users’ expectations about performance, availability, usability, reliability, and other quality attributes. It’s also important to surface pertinent business rules, design and implementation constraints, and assumptions the various stakeholders might be making. The objective is for the BA to understand what customers are envisioning so he can record both functional and nonfunctional requirements that will guide the development team’s work. Furthermore, documented requirements and user acceptance criteria will help testers determine whether the delivered product satisfies its requirements. When eliciting user requirements, the BA typically works with a number of key users who represent specific user classes. The BA needs to ask questions that will help those users describe the goals they want to accomplish with the help of the system. For most types of software projects, this is far more valuable than the traditional focus of requirements discussions on...
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...
