In the good old days of business process automation (until late 1990s), measuring success seemed much simpler. Software teams could say, "There is an existing way of doing things. Let's automate that, but stick to budgets, timelines and quality metrics." Goals were simple and measurable. Software design was never discussed. User experience was nonexistent. Business impact was purely profitability based and no behavior changes were hinted at. Even as we moved into the era of Agile, business folks would give us weird looks when we asked to speak to end users. A client once told me, rather dismissively, "We're building this (app) for accountants. They don't have an eye for color. I don't know why you're worried about user interface or design." He may have made total sense a decade ago.

Today, you'll easily hear a CEO say things like, "We need to create stickiness, and to ingrain in our users a desire to engage with our apps." Many a product manager will roll their eyes and think, "Whatever that means." Success for a product is no longer about meeting budgets or timelines. The narrative of software development has changed. Can product management afford to lag behind?

Understanding business goals and evaluating risks and costs have always been essential for driving trade-off decisions. Business goals today are multidimensional and so are risks. How we make trade-off decisions depends on what aspects of product success we want to consider. Today, a product manager has to handle many facets of goals and risks, before defining the right product to build and driving trade-off decisions. According to the management consulting firm, McKinsey & Company, "Product managers are the glue that bind the many functions that touch a product—engineering, design, customer success, sales, marketing, operations, finance, legal, and more. They not only own the decisions about what gets built but also influence every aspect of how it gets built and launched."

Traditional project planning isn't going to help anymore. Product managers are in the driver's seat. We have to steer the product to meet ambiguous business goals. When building disruptive products in ambiguous business conditions, there is no "existing way" to refer to. All we have is a bunch of glorious ideas. So, the first step to demystifying goals is to articulate intent.

Impact Driven Product development needs to consider four key pieces of input that influence and guide product success:

A business as a whole has its own value creation goals outlined. A product may address some or all of a business' goals.