In my prior blog, I shared that the Product Canvas is a tool anchoring a shared understanding of your product. Part 1 of the canvas provides contextual and strategic information. Part 2 summarizes the key compositional element of your product requirements using the 7 Product Dimensions.
Ellen Gottesdiener
Know Your Product with the Product Canvas
What is your product?
If you ask your product development team members, product managers or owners, colleagues in finance, service or operations, marketing, sales, compliance, and all the other departments and teams that make up your organization, would they agree?
It might surprise you to realize that for many organizations, not everyone has clarity around something so fundamental. I’ve developed a Product Canvas to address this issue. The canvas also helps product managers or owners proactively steer their products.
Value: The Lynchpin in Agile Product Management
You’d think the topic of value would be straightforward when it comes to agile product management and ownership. After all, early and continuous delivery of value is the first principle in the Agile Manifesto and product backlogs need to refined based on value.
And yet, value is not easily defined, qualified, quantified, or agreed upon.
With many smart, experienced folks together at the Agile Product Open last month, I decided it would be informative to propose the topic “Value: The Whats, Whys, and Hows” in the marketplace of ideas.
To start the conversation, I offered my favorite definition, borrowed from the Value Standard: fair return or equivalent, in goods, services, or money, for something exchanged. From there, our conversation grew richer and deeper.
Guest post by Ellen Gottesdiener: Agile Product Ownership – 9 Essentials for Product Success
The key to product success is to discover and deliver the right product for the right customers—and to do it at the right time. That doesn’t change when you move to an agile way of working. In fact, appropriately applying the agile mindset amplifies the imperative of eliciting and specifying the right requirements. The goal is to deliver the highest value product needs (requirements) in as short a time as possible.
Continue reading
Guest post by Ellen Gottesdiener: Exploring Product Options to Arrive at Right Requirements
When is a so-called requirement really required? And is it the “right” requirement? The answers depend on many facets: stakeholders, value, planning horizon, and so on. This article explores using options as a means to identify high-value requirements, at the last responsible moment.
My Requirement May Be Your Option
Product requirements are needs that must be satisfied to achieve a goal, solve a problem, or take advantage of an opportunity. The word “requirement” literally means something that is absolutely, positively, without question, necessary. Product requirements must be defined in sufficient detail for planning and development. But before going to that effort and expense, are you sure they are not only must-haves but also the right and relevant requirements?
Continue reading
Guest post by Ellen Gottesdiener: Strenghten Your Discovery Muscle
Here comes a new post from Ellen Gottesdiener who comes to Stockholm to hold her highly appreciated course Agile Requirements Analysis and Planning for Product Success.
In a recent interview in the New York Times, Panera Bread co-CEO Ronald M. Shaich talks about the importance of developing an organization’s “discovery muscle” as well as its “delivery muscle.” Most companies have worked hard to perfect delivery—how they get work done—he says, because delivery “feels rational, people feel much safer with it, and you can analyze it.” But discovery—the activities you undertake to define or change your product, service, or market—is about “leaps of faith. It’s about trusting yourself. It’s about innovation.” The key, Shaich says, is for the discovery muscle to be at least as strong as the delivery muscle.
He took the words right out of our mouths. This need for balance between discovery and delivery applies in spades to software development. Our new book, Discover to Deliver: Agile Product Planning and Analysis, explicitly makes the case for equally balancing your commitment to these key activities. We define the relationship between them: In lean/agile software development, discovery and delivery are interwoven, interdependent, continuous activities (see figure 1). Each feeds the other.
Guest blog by Ellen Gottesdiener: It’s the Goal, Not the Role:The Value of Business Analysis in Scrum
Ellen Gottesdiener is an internationally recognized leader in the collaborative space where agile requirements + product + project management converge. She coaches, trains, and presents to thousands of people globally and has facilitated hundreds of discovery and planning workshops across diverse industries.
She will hold her popular workshop in Stockholm 25-27 September 2013.
It’s the Goal, Not the Role:The Value of Business Analysis in Scrum
In agile development, what happens to the traditional business analyst? Consider Scrum, currently the most popular agile method. In Scrum, there is no “business analyst” role. In fact, there is not an explicit role for tester, project manager, architect, developer, data administrator, user experience designer, customer support representative, or product trainer. Instead, Scrum has three roles: the product owner, the Scrum Master, and the delivery team. Their collective goal is to deliver high‐valued product needs continually. So, where and how can a business analyst contribute?