I shot an interview with Adolfo Foronda about building the right product as a product owner. Check it out! Click “Continue reading” below for my speaking notes, which are an approximate transcript.

The Product Owner must continuously engage the customer and stakeholders to ensure the Team is building the right product. How do you get a sense and ensure the customer and stakeholder are getting it or not? How do you measure or verify that the customer/stakeholder understands what the product does or should do?

If you can’t describe your product or vision in several words, your customer or stakeholder probably won’t understand what the product does or should do. I think the best litmus test is simply their facial expression, body language, and verbal response when you explain it to them. And, yes, this means that you should be having most of these conversations in person.

We can elaborate on this, of course. There are two ways of doing this, both of which are appropriate at different times in the product development cycle.

At the beginning of the cycle, we’ll have some fabulous idea for a product. At this point, it’s good to create a quick prototype of the idea and start showing it to customers. It should be ugly enough that a) it doesn’t take you too long to create and b) your customer doesn’t get stuck on irrelevant details. It should be clear enough that your customer could imagine themselves using the product in their context. Do this in person if at all possible with two people from your team: a UX researcher leading the interview, and a product manager taking notes. Record if possible as well.

If people get excited about what you’re showing them and start trying to give you enhancement ideas, you’re probably on to something. Don’t stop there: ask about the problems they’re trying to solve. What would that proposed feature allow you to do? Better yet, which other products would they stop paying for and using if they had your product instead, and why?

How can we detect if the product is not fulfilling the customer/stakeholder needs/expectations?

Sprint Review, at a minimum. This isn’t a dog-and-pony show for pointy-haired managers. It is your opportunity to celebrate your team’s accomplishment and get real, honest feedback about your work. Of course, this only works if you are shipping well-written, vertical user stories.

If you can start user acceptance testing earlier in the process, even better. There’s no reason why a mature team can’t ship an increment to at least a demo environment and get real user feedback every single week, if not even more often. Shipping to production is even better.

If not how do you course correct?

All of Agile is designed for rapid learning. Every single Agile event and interaction is an opportunity to inspect and adapt. Plan, but as soon as you are done planning give up attachment to your plan. This is why the fourth line of the Agile Manifesto is “responding to change over following a plan.”

Course corrections are merely the manifestation of learning. Before one can learn, they must be willing to admit that they didn’t know, understand, or even that they were wrong. The rest is the same planning in the first place: think—but not too much—about what you know, chart a rough course of action, and get moving!

Have you terminated a Sprint if it is determined that a drastic change in direction is required? If so please explain the scenario and what was learned.

The abnormal termination of a sprint is a very strong action that carries a connotation of failure. I don’t recall a single time in my career where I’ve have wanted to use it.

Sprints are usually terminated because a) there is a change in product direction or b) things are taking much longer than expected and we no longer think the work is that valuable. Rarely would this apply to every story in the sprint backlog, so this shouldn’t happen on mature teams with strong product managers very often. If it does happen on a mature team, why not just get together, discuss, and decide what to do next? Ideally you’ve got at least half a sprint of ready stories in your team backlog anyway—because you go into sprint planning with 1-½ to 2 sprints of ready stories—so you could always drop one story and pick up another. You don’t need to go through a whole round of review, retrospective, and sprint planning again. Besides, if you’re in cadence with other teams, why lose that?

For an immature team, they’re already in chaos. Start them with 1-week sprints. The next sprint will start in an average of 2-½ days. It’s OK if they “fail.” We can learn from that. But no need to rub anyone’s nose in it.

As a coach, I’m having a hard time thinking of a time where I would have wanted to recommend a termination to the team for these very same reasons. We can work through it with less trauma just by talking openly and honestly with one another. After all, we’re a team.