In a previous blog post, Brenda Peshak discussed the “Definition of Done”. As a team, we ran through an exercise to understand requirements and determine Minimal Viable Product (MVP). This got me thinking about real life examples of software and how decisions made by product owners and product managers directly impact our day- to-day lives.

Again, this became top of mind on my way to speak at a conference on Inquiry- Based Education. As I flipped open the Maps app on my iPhone and punched in the address of the conference, I was greeted by several accident notifications on I-80/I-35. If I took the most direct route, I was going to be late. The obvious solution was to use one of the alternate routes provided to me by the Maps app and I arrived on time to the conference (albeit a few minutes later than I expected). I could not have imagined a more perfect real world example for my speech!

Somewhere in Cupertino, California, a product owner/manager asked the right questions to prioritize crowdsourcing accident data from other users of their Maps software, and providing that data back to other users of the Maps app so they could make informed decisions. Determining the right questions to ask is imperative to determining value, such as:

1. Who are our users and how do we understand our users?
2. What is it that our users of our software need?
3. In this case, how was the choice to provide real-time traffic data determined to be a higher priority over other feature work that could be accomplished?
4. What questions did the product manager ask their developers to determine if the feature was even feasible?
5. What about timelines to complete?
6. And balancing the cost of this feature vs other features?
7. If multiple solutions were provided, how did the product manager determine which solution would make the most sense?

Inquiry doesn’t stop with the product owners and managers; the entire team needs to ask questions. Developers should be asking questions about the prioritization of stories and features and asking about how the stories and features fit into the overall project and product. In addition to asking questions about the architecture and non-functional requirements, they should also be asking questions to ensure their solutions will actually meet the needs of the end-user and bring value to the product. Our teammates should be asking how a story or feature should function and about alternate scenarios that no one may have even thought about. User experience should be asking questions about how users would use the product once complete and whether the individual solutions make a consistent and well thought out overall product, preventing a disjointed experience.

I ultimately realized that the successful agile teams I’ve been on ask these questions without hesitation. They truly want to understand the users and build software that has the highest priority, makes the most impact, and is designed in a way that makes sense for those end-users.

In the end, what value is there in software that no one uses?