The Whole Product


There's more to a product than just the core software and features, and all those other parts are often the first things you see and judge about a product. They make up your initial experience with the product, and the quality of that experience will affect your opinion of the software.

Given that there's so much to a product, who on your product team do you see as responsible for designing, building, and testing the product? For any given product you work on, ask the following questions:

  1. What are the components of your customer's and user's experience with your product? Your list should include everything the customer and users see and touch
  2. Who is responsible for designing, constructing, and validating each component?
  3. How do all those responsible collaborate with each other to ensure a high-quality product?
  4. How is the entire product tested? How do you determine the success of the finished product, and how do you determine where it can improve?

As software development matures, often the thing separating high-quality software from lesser counterparts is the user experience. While I think it's a good idea, I'm not ready to insist that software should go the way of building architects—training people who can effectively design the inside and outside of the product—we should consider the whole product when we design, build, and validate. And, from a process perspective, if we can't get all those brains into one body, I hope we can get them to collaborate as closely as possible. The success of the whole product depends upon their combined success.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.