Technologists and Product Managers: Focus on Business Value
Business value is related to many factors, such as customer satisfaction, retention, and new acquisition. It's also a factor of technical excellence for better design, development, and deployment, ilities requirements - performance, scalability, availability, and so on.
These are the opening words from Martin Fowler and Ian Cartwright, in their article titled The Elephant in the Architecture, addressing to techies, primarily. (Read it in full, made some excellent points)
We, and our colleagues, are often called on to perform architectural assessments for our clients. When we do this, the architects involved with these systems will talk about the performance of these systems, how resilient they are to faults, and how they are designed to evolve to easily support new capabilities. The elephant that rarely comes up, however, is how different systems contribute to business value, and how this value interacts with these other architectural attributes.
Coincidentally, a few days ago, my lede in Jobs-To-Be-Done: Your Go-to for Product Management & Strategy
So often we hear about how feature-rich a product is, but what we need to understand more -- what value is it bringing to our customers. You may have heard the often quoted: "Customers don't want a quarter-inch drill-bit but a quarter-inch hole." While that line of inquiry is directionally correct, it needs to go much further out ... "Why do they need that quarter-inch hole(s) in that wall?"
While we come from two different aspects -- architecture and product management -- the focus area is the same. Developers and architects need to know "why" they are building or designing a system. Product Managers take the lead on the "why" of the business value proposition. Before building a solution, at a minimum, drill-down into the customer's desirability and business' viability.
Business Value is Much More than Revenue Dollars: Don't look into the question myopically as to whether by doing 'X,' am I driving more revenue. Revenue, while a critical part of the equation, consider what other outcomes can you drive -- intellectual property in a competitive landscape, data acquisition that can help in mining and analytics, marketing benefits promoting user engagement.
Communicate Strategy: As a product leader, you can and should tweak the plan based on the feedback, but you have to have a solid strategy in place before you get into the execution. The process of forming a good strategy can be iterative, and yes, dedicated design sprints are good. Once you have the strategy ready, tirelessly communicate. When you get tired of relaying it, the people may have just started paying attention! Repetition works.
Value-stream Mapping: Fowler mentions Value-stream mapping to be a great way to asses the value of every proposed feature. I have used Wardley Maps with success in the past, and recommend similar exercises, including customer journey mapping.
Ask, "And, Then What?": For the decision making as an individual or team, in a business context, aim to go deeper beyond the immediate response. Look for the second-order consequences of the choices you make. Practice Systems Thinking. For example, designing a solution, and racking up technical debt unknowingly is no fun. But taking on technical debt after carefully considering the consequences and tradeoffs is a prudent approach.
Build a culture of equals and partnerships: Product is not some superior entity, nor the Product Managers are mini-CEOs. Successful product discovery and execution is all about the right connections among the cross-functional leadership across product, development, design, marketing, sales, and more. A few years ago, before widespread cloud adoption, an IT leader told me, "every business leader wants "five-nines" until they hear what it costs." Well, that's where partnerships come handy. Educating each other, discussing tradeoffs, and questioning each others' assumptions openly.
Form a purpose-driven core group: a business person, technical lead, a designer, or data analyst (based on your system's needs). Laser focus on the question of why do we need to build this. What are financial incentives, whose behavior are we changing, what is the cost of the delay, who would miss the functionality if you never deliver
Being Agile over doing Agile: Do not get stuck in the process-jargon. Agile, Scrum, [inject your favorite process here] are useful for product delivery. For product discovery or optimization, the same constructs won't work. You are talking about experimentation, instrumentation, and metrics as your guides.
Validate, validate, and validate: Assumptions are necessary to move forward, otherwise you are stuck forever. Uncertainty is part of the business. Things are rarely black or white: several shades of gray is the norm. How quickly and cost-effective way can you validate your assumptions holds the key.
Prototypes (minimal coding, if possible): Goes along with the previous point -- start with a prototype first for risky bets. See if you can do so without significant investment in actual development, even if it means the overall user experience is sub-optimal. I understand it's not possible in many cases. Try it. Your goal is to determine whether you are on the right path of providing the business value or not.
Let Business Value be at the heart of your strategy, planning, and execution.