To create successful products, it is crucial for a PM to understand the underlying reasons behind customer’s behaviors, challenges and expressed needs. However, by actively listening we can uncover the underlying goal of getting from A to Z, rather than optimizing individual steps along the way). Then, building on a base of solid domain research, and engaging with multiple prospects, we can know if there is a pressing (impactful), widespread (or even universal) pain point that a buyer is willing to pay for. Then we have found a market for a product (or product feature) to fit into.

For the PM team, the focus then shifts from listening to customers to listening to designers, engineers, data scientists, and GTM team members to craft an ideal solution based on what is technically possible (given the time available and resources on hand). Functionally, the role of a PM becomes one of facilitator, tie-breaker, and dot connector, keeping conversations moving and bringing them to the right level. This creates a shared vision of the business need that includes team members' input, priorities, and commitments.

The most challenging part for the PM team is refining this solution to an MVP. This requires a constant (and quick) feedback loop with customers (ideally real customers, or possibly customer surrogates) while working closely with design (mockups) and engineering (point POCs for feasibility). The goal is to listen to what the customer reacts to, how they would use that proposal, and who they would want to bring into the conversation “next.” This allows us to identify the buyer (and other stakeholders), the salient features, and how the product (or product-feature) would be best positioned to get customers excited. The goal is not to de-risk the product, but for the entire team to understand what decisions were based on direct facts, general knowledge, or hunches. When customers align, the team has found its MVP, and a roadmap can be charted together

The mark of a junior designer is one who sees completing a design as the outcome of their work: There was an ask, and the designer provided the solution. However, that approach misses the true value of design. It often makes the designer feel that any criticism of that output is a personal reflection on how well they did the assignment, and keeps the junior designer innovate for larger, more strategic, impact. Instead, senior designers know “better” designs will always come in the next iteration, and that each design should have an opinion that forces the current stakeholder to react and articulate feedback. This feedback are data that you almost never can get before you hold up something visual, so the quicker the time to feedback, the quicker to the next “better” design, the faster to success.

In my time running my B2B design/dev studio, I instilled this different philosophy with my team. I framed our goal as “trying to have a conversation with the client.” We must always assume our designs would be thrown away after that conversation. And each round of design must be extremely fast (we should be able to compete 2-3 rounds in the same time most people do one). If perfect is the enemy of good, than good is the enemy of feedback. Eventually we stop iterating (because we have converged on a solution, or because of bounds from time/budget constraints, etc), but the outcome isn’t the design - the outcome is the deeper understanding. For example, when doing logo design - we should present a number of ideas, and then get feedback from our client, helping them better understand what needs to be communicated in their vision which then informs the next design. It is like holding up a mirror. Thus the vision, company strategy, and the next set of designs all improve. I have had customers change their company tag-line, radically adjust vision statements, abandon product directions, or focus on sub features simply by making sure everyone knows that we don’t care about this specific design: its only use is to start the conversation.

What is beautiful about this approach is that it can be as long or short as you need. One conversation always leads to another, but stakeholders (and the larger product process) continue to move forward through this process. Consider a mockup facilitating conversations with a PM, improving product requirements. At some point, a product based on those mockups becomes an interactive prototype, creating a shared reference point for a dialogue with a prospective customer. Then again, those prototypes become design specifications for front-end engineers, and conversations with middleware, backend, and data science engineers on how to best craft a solution. And ultimately, what is a product but a design (in code), that allows customers to have conversations with their data, their own customers, the sales team, or the product/user-research team to start the entire lifecycle again.

This is true for UI, UX, brand, slides, posters, banners - you name the medium, design is about learning, listening and iterating (and making pretty pictures along the way).

In most software-based companies, the most valuable resource is time - in particular, software development engineering time. Every organization I have worked for wished for more developers working in parallel on more efforts to accommodate their customers.

In this regard, design and product should be viewed as integral parts of a method to de-risk committing development resources. So while design and product should work ahead of development, developers must still be part of the conversations with design and product.
When leading engineering, conversations are ultimately made easier by exposing the business constraints to the team, and helping each team member understand not just the what, but why a feature is needed. If they can understand the why as the primary motivator, then each engineer becomes a stakeholder. They become responsible for crafting an outcome - not just building a widget.

Thus, bringing relevant stakeholders together early, often: providing context and getting feedback is critical. If handled correctly, engineering will not feel like they are on the receiving end of decisions made by others. Ultimately, this comes down to cross-team cohesion: building a consensus across all team leads in product, design, and GTM.

The ultimate outcome then is that by establishing a formal process for ideation, review, hand-off and continued engagement - everyone’s voice is heard, constraints from all parties are incorporated, and design and product are viewed as knowledgeable and not arbitrary dictators.