The missing bridge between strategy and execution
Building an IT product business can be quite challenging if you don’t have certain foundational elements well understood and institutionalized. This applies to not just startups but large organizations too. The goals in any sized company are similar. For example, getting a new idea out to market, entering new markets, trying to achieve scale, reducing cycle time between idea to market, reaching the right set of customers etc. Large organizations will need to maintain their leadership positions by continuously innovating, whereas startups agile nevertheless, have a lot less room for errors due to scarce resources. Some of the symptomatic situations of a shaky foundation are; building a new product with several features without involving potential customers; depending heavily on sales to gather customer requirements; misaligning outsourced development outcomes; mixing custom solutions and products while positioning etc.
There is an implicit operating model in product organizations, which has rarely been explored or discussed so far. An operating model describes how organizations execute. Imagine a product team – what conversations do they have to execute their goals and strategy? How are information and decisions flowing between team members and with their external stakeholders? Is it aiding or impeding their speed of execution and thus eventually their business? This is not to be mistaken with functional best practices in creating or marketing a product successfully, rather this is more foundational for any product organization. There are four factors for that make up the operating model for product companies and they are product mindset, organizational design, development model and decision making structure.
Product Mindset
Mindset is the basis of culture. Product mindset can best be described as the set of beliefs and assumptions that power the creation of inspiring products. Our beliefs and assumptions are hidden deep in our psyche and it takes a conscious effort to realize and shift to the mindset needed. The challenges are in unpacking the beliefs and repacking them with new ones that enable creating products. The mindset drives how we perceive success, failure and efforts in every aspect from deliverables to revenues.
For example, if the customer asks you to add a feature for them, do you jump on it and implement or do we understand why do they need it and how does it help them? Do we also pause and collect data points from other customers on similar needs and then begin to work on it? It is easy to mistake a customer’s ask for Promise to Pay. Instead we should explicitly check for Willingness to Pay before launching the product.
There are three assumptions we need to watch out for. First, are we paying too much attention to what the customer is asking us to do instead of understanding what they really need? Second, are we jumping into technical solutions before spending enough time trying to understand the problem and reframe the problem in multiple ways? Third, are we building for each client instead of exploring repeatability for many?
A good product organization considers product failures as valuable learning lessons (as long as you can afford it) and success only when you have happy, paying and returning customers. Shifting to product mindset requires sustained effort. Ideation or brainstorming is one of the ways. Exposure to inspirational stories is another. Several companies encourage new ideas through internal hackathons but fall short of nudging their employees to think bigger and from a customer point of view.
Organizational Design
Organizational design looks at reporting structures and size of teams. Engineering, Sales and Marketing are well defined organizations. Product companies need a Product Management organization that reports to the CEO. This is not to be confused with the Marketing organization, which is essentially Sales in internet consumer companies. It is important to balance the perspectives of engineering and sales with a product management team. Very simply put, product management organization is responsible for representing customer interests during product development. A good Product Manager recognizes and navigates through the dynamics while diligently advocating for the customer regardless of reporting structures. It is not easy to balance with generating revenues or feasibility constraints.
A typical product team consists of a product manager, designer and several engineers. Product ownership is critical and a basic ingredient to making the product a success. Some very successful global product companies have figured out that a good team size is which can be fed with two large pizzas. That’s roughly 8 including engineering, quality assurance, designer and product manager. Being able to do “more with less” is an oft-heard statement. Most founders in startups are the first product managers but quickly exceed their bandwidth. An easy milestone for the founder-CEOs to know when you need a product manager is when you are not able to spend enough time with the customers. Even though customer empathy and advocacy is something that the whole organization should embrace, a product manager can greatly help drive the process.
Development model
Product companies must build in-house engineering talent which they usually do. For startups, it is becoming increasingly expensive as well-funded companies are going all out to attract top talent with much better compensation. Large companies may also want to hire someone outside for temporary work to rapidly build a proof of concept. So, there have been and will be situations that require the team to outsource development. When product companies outsource development, there is a great amount of risk in velocity. The difference between the client and the vendor is in operating rhythm. The outsourced vendor expects a well-defined Statement of Work with fixed scope to ensure quality and timely deliverable. This is the antithesis of product development where scope is inherently flexible and changes during development are almost a given in the first few versions when working closely with customers. One way to getting around this problem is for vendors to innovate their business models and/or engagement models so that the lines are blurred between consultants and core team members. For this to happen, the conversations between the client and vendor needs to change from time and materials based outcomes to value based outcomes.
Decision making structure
There is always an element of continuous discovery and refinement in the product world that demands continuous decisions. We need to embrace this uncertainty at the same time work towards minimizing the risk. Modern methodologies like The Lean Methodology greatly help in minimizing the risk by cutting down the time taken between implementation and feedback. Also, with the advent of experimentation tools in the market, it is easier to compare user behaviours. For e.g. do the users click more when presented with a green button or a red button. Product level decisions should be clearly aligned with business goals set by the executive leadership. It becomes easier to evaluate and track product performance and impact on annual targets which is also very rewarding in high performance teams since they are visible and recognized. Most product organizations have a flat hierarchy that enable easy collaboration and brainstorming.
In summary, it may be useful for product organizations to pay attention to their operating model while working on strategy and execution.
