Ask Three Simple Questions To Build Great Products
Products that your customers love
The scale and success of a technology company depends on two functions: Product and Engineering. When they work well, the company thrives and succeeds. But when Product and Engineering fail to operate and execute well, it negatively affects product outcome, customer experience and revenue.
In organizations where Product and Engineering are in constant friction, it often results in a lack of ownership and outcome. When ownership over decision making is displaced, projects take longer to finish. This results in long-winded product backlogs and lack of focus and execution in the organization.These challenges can become massive, with seemingly no light at the end of the tunnel. If this disconnection is left unaddressed, it can mean the beginning of the end; the colossal failure of a company.
I want to highlight two common cultural elements behind failing Product-Engineering organizations:
1. Lack of clear accountability and ownership
2. One team over-influencing the other
The former, lack of accountability and ownership, is explicitly seen and experienced in failing organizations. The latter, over-influence of either the Product or Engineering team, is more subtle. However, one leads to the other.
A lack of accountability and ownership can result in teams indirectly doing other peoples’ jobs, therefore influencing the process beyond their expertise. A common example of this would be a Product Manager directing the Engineers on how to technically solve a problem, and on the flip side, the Engineers being strong critics of the Product Roadmap or Product Vision.
In these scenarios, ownership and accountability becomes muddy, and at times, people wonder what role they should play.
When there is lack of accountability and ownership in Product and Engineering organizations, companies put in massive investment and effort to rekindle the spark between Product and Engineering. And often, that means an offsite meeting to talk about the challenges they are encountering. These provide little value if there is no explicit path to execution. So, the cycle repeats again and again.
Here is a twist to enhance the Product-Engineering relationship, so you meet deadlines and deliver impact to customers.
Why-What-How Golden Circle:
Simon Sinek, an inspirational leadership speaker, introduced a framework called “The Golden Circle” for leaders to inspire action through communication. It brings purpose and clarity on the path to execution.
I use the Golden Circle framework to share direction and communicate decisions to my teams, and it has landed well every time. I’ve adopted the same approach to engage Product and Engineering teams towards delivering outcomes.
The key to the success using Golden Circle to build impactful products
The Golden Circle conveys the problem (Why), what we are doing to address the problem (What), and how we are going to address the problem (How).
Effective communication, clear ownership, and accountability are the key elements in the Product-Engineering relationship, and this can be achieved by adopting The Golden Circle.
Why is it important to talk about the problem you are solving?
Do not attempt to solve a problem unless you know why you are solving it in the first place.
Defining and clarifying the “why” lies with the Product Management team, alongside the Product Strategy and Research teams. If the Product Managers are not confident about why the problem needs attention, it’s time to dive deeper to the source, rather than skip to devising a solution.
Most Product teams are adept in identifying the “why”. But they do not communicate it properly to their Engineering counterparts. Instead, they quickly move on to defining what needs to be built to solve the problem. Over time, the value of “why” diminishes, and when the teams reflect, they only talk about what they built; nobody understands why it was built in the first place. This translates to the customer as well. Vigorously communicating what has been built, without including how it solves a core problem, is not a sufficient statement of value.
Product Management does not only have ownership over defining the “why”, but also the responsibility to communicate it to stakeholders. Different companies use different channels to communicate the “why”. I recommend creating a document — call it a requirements document, feature vision, or an Amazon-style press release document, but make sure a document exists that clarifies the “Why” and share with stakeholders and seek feedback.
What can be done to solve the problem?
Once the problem is defined and communicated, the next natural progression is defining what needs to be built to solve the problem. This is the perfect time for people who are envisioning a solution (Product Managers) and people who are building it (Engineers) to come together. Ideally, the “what” is crafted through brainstorming sessions.
The process of building a feature or refining an existing one is a collaborative effort by Product and Engineering teams. It is best that the Product Owner or Product Manager organizes the brainstorming sessions, and invites all necessary stakeholders to participate. Be mindful to include everyone who needs to be there for a successful outcome throughout the process.
Identifying a solution to a problem is not constrained to Product and Engineering teams.
People who experience the problem (customers) or teams who work with people experiencing the problem (Customer Support, Sales) should be included as well. If you are solving an inconvenience for your users that has been reported multiple times, you should include Customer Support and Customer Success at the solutions table. If you are solutioning for a new feature, then invite the Sales and User Research teams to participate. The feedback they’ve heard from your customers is valuable, and can inform solutions.
Once there is an alignment on what needs to be built to solve the business or user problem, the Product Manager or Product Owner should articulate it — call it a Feature Description artifact. This is also the time for Product and Engineering to agree on how the feature can be delivered in multiple iterations. Do not wait months to solve a problem.
Clarity around why you are solving a problem and what you can build to solve the problem will give you enough confidence to piecemeal the solution, so that your customers get a taste of the solution early on.
How are you solving the business problem?
The last phase of this framework, how to solve the problem, is where builders (AKA Engineers and coders) put their heads down. Is the new feature created as a separate microservice, or embedded into an existing monolith? How do the services talk to each other? Is there a need to introduce a new service from the Cloud platform? Most of these are answered by Engineers.
Engineering teams often spend ages to define the “how”, because they want to be pixel-perfect in solving the problem. This is anti-agile.
The grand architectural vision should be broken down into micro-architectural decisions, so that the solution is delivered incrementally to customers.
Architectural decisions made by the Engineering team during this phase are sometimes primitive, and don’t take into account a number of unknowns. Engineering teams also make a number of assumptions during this phase. It is important to document these assumptions so that they can be validated with relevant stakeholders.
As much as Engineers hate to share an estimate of when a feature can be built, having high-level estimates will help the business be predictable. Sharing SWAGs (Simple Wild Ass Guesses) or “T-Shirt size” estimates will keep the whole business informed about whether the first iteration of the solution will be delivered in weeks, or months. Being candid about the estimates will also help the business draw reasonable conclusions about the ROI of a new feature.
Why is the Golden Circle impactful?
In my experience, leveraging the Golden Circle to build your product has many benefits.
Golden Circle compliments agile, prevents organizational bottlenecks, and delivers results. It also delivers clear ownership and accountability for different teams engaged in the process.
It preempts Product and Engineering teams to invest the time to build the right solution for customers, and validate their value hypothesis before putting their hands on the keyboard and delivering lines of code. All of this builds transparency and improves engagement between Product and Engineering. And the result is an organization that solves the right priorities for the customers, and where people feel impactful about the problems they are solving.
