Table of Contents

Necessary Alignment

Every person working on a software effort has the right to understand what they are trying to accomplish and why. Understanding the product goal will give team members clarity in decision-making throughout the effort.

Further, alignment behind the goal—communication of it and acceptance of it by the entire team—enables people to make sound decisions without explicit guidance every step of the way. Alignment behind the goal will transform a product owner’s job from fighting fires and walking team members through every single decision to a much more predictable workload focused on providing vision and context.

No Product Goal Means No Product

Not understanding the goal leads to incredible problems. I took over a development effort for a mobile payment system shortly before its go-live date. Unfortunately for me, I did not know there was an imminent go-live date. And unfortunately for everyone else, missing this date—which included a large premeditated marketing push, verbal commitments to billion-dollar customers, and written commitments to bring millions of users onto the system from existing complementing services—would mean that my customer’s business would shut down overnight.

I discovered this go-live date less than a day before the deadline. The entire system was barely in a usable state for internal testing, let alone something ready for a production environment that would quickly grow to millions of users. I worked a 27-hour day, trying in vain to hit the deadline with all features completed. While I didn’t complete everything that was promised, I did get the system to a state where my customer could reset expectations on the feature list and continue with the launch.

This last-minute panic could have been avoided entirely with advance notice of the goal. We were launching a system that would secure business for my customer for years to come, and I knew nothing of their plans. Prior to this all-nighter, I thought the customer had not yet formalized any plans beyond “build it and they will come.” How eye-opening it was to see the actual plan! As you might imagine, this discovery led to a quite heated exchange with my project manager.

Sharing the Product Goal Promotes Understanding

Certainly, the project manager could have handled things differently. The plan could have been clearly communicated to me as soon as I joined the project. Similarly, though, I could have asked for the information I didn’t have. Instead of assuming that there was no goal, no milestones, and no deadlines, I could have asked what we were working toward. Understanding the product goal and the customer’s expectations earlier on would have resulted in an earlier prioritization of remaining work, and perhaps a change in timelines or commitments that would have made the entire team feel more at ease with the final sprint toward the finish line.

Identifying a Product Goal and Objectives

When joining a product team, the first thing you should seek to understand is the product goal. Asking may be enough: the product owner should know the goal to strive toward. If the product goal can not be stated simply and succinctly, you may need to assist. It is the product owner’s responsibility to define the goal, but team members can help tease it out with a few clarifying questions:

  • Who will be using what we build?
  • Why will they be using it?
  • How will it impact their work?
  • What is the most important thing they need?

Product Goal Statements

Later, once you have a clearly defined goal, a goal statement can be used to drive future product decisions. Framing a decision in terms of the goal should reveal a clear answer about how to proceed. If a decision will not align with the product goal, choose to do something that will. If you are not accomplishing your goal, you are detracting from it. Non-goal tasks can eat up your budget (time and money). Goal-oriented tasks and objectives give your product a higher chance of success and increase your return on investment. Therefore, define a product goal statement so you can determine what tasks make the most sense for your team to prioritize.

Here are a few goal statements that I have seen in the past:

  • We maximize the time educators spend with special needs students.
  • Our product helps people with dietary restrictions discover appropriate and delicious meal options.
  • We save lives by minimizing first responder response times to reach the scene of an emergency.

The product goal should be simple, and every decision your team makes should support the goal. Business requirements should make sense when measured against the goal. Given the example goal of maximizing the time educators spend with special needs students, we may find that auto-filling form fields to save time on data entry is in alignment with the goal. Introducing a feature to change color schemes, however, will not help us reach our goal because it does not provide any time savings.

Goal-Oriented Tasks Improve Your Product's Future

The product owner should determine the value of business requirements. However, keep in mind that any functionality you build now—no matter how simple it may be—is functionality you will spend time and money supporting in the future. If you believe that a business requirement does not align with the product goal, you should discuss it with the product owner.

Are you unsure of how to identify your product goal? Do you want to better promote goal-oriented thinking on your team? If so, start a conversation and we’ll be happy to toss around ideas.