Product Company Org Structure. A Wild Aspiration.


Gopal Shenoy,  product management leader and a famous blogger, made a blog post on how a product manager is not the CEO of their product, and one of the main points of contention was that, unlike a CEO, a product manager has no authority, and hence product managers are encouraged to work in the lines of influencing cross functional teams and position themselves as the Chief Influential Officers (CIO) of their product.

Whilst I agree 100% with Gopal Shenoy’s view of product managers as CIOs, I’d like to make a proposal on how to achieve the CEO tag which will make us better product managers with higher levels of responsibilities.

Definition of a Product Manager

Here’s a good definition of a ‘product manager’ that I bumped into recently.

Product Manager - good definition

Source: Anonymous

One of the key aspects in this definition is the product manager’s responsibility and ownership over the product deliverable — we all agree we have that responsibility.

The Reality

Based on my experience, I feel the ‘responsibility & ownership over the product deliverable‘ is extremely challenging to exercise with the org structure of today’s tech companies. Engineering management has too much control over their engineers, especially around working on a defect vs. a subtle refinement based on product manager or dog-food feedback — this is because they think they own the delivery of the software features. Just too much authority based thinking. Engineering’s focus is more towards securing their position, name, etc. rather than shipping a great product that has market/customer acceptance. The hands-on engineers tend to listen to their bosses more than the product manager because they have to look good to their bosses for around performance assessments.

No matter how much there is excitement about flat/matrix organizational structure, layers get developed within engineering teams over a period of time for various reasons such as career advancement, retention strategy, etc.

Proposed Org Structure

As an aspiration, I’d like to propose an org structure for product companies, with the intention of ensuring fairness to product managers in fulfilling their responsibilities.

Product Manager

  • Reports into VP/Head of Product Management
  • One or more projects assigned to each product manager
  • Engineers assigned to the project will officially report into the product manager
  • Works with the assigned designer, architect, and engineers in delivering increased customer value, eventually leading to exceptional product-market fit
  • At the end of the project, or on a periodic basis (e.g. quarterly), provides feedback to head of engineering on the performance of engineers
  • Team reporting into product manager for each project

    • Designer
    • Architect
    • Developers
    • Testers
    • Scrum Master
    • Analyst

Engineer

  • Reports into assigned project’s product manager
  • Reports into Director/VP/Head of Engineering on a dotted line
  • Collaborates more with product-manager vs. his/her boss
  • Works with Architects to groom their technical skills
  • Brings innovative problem solving ideas to the table

Director/VP/Head of Engineering

  • Works with VP/Head of Product Management in understanding project priorities
  • Align with rest of the leadership on resource assignments across projects
  • Use feedback from product managers to assess performance and rewards for engineers

Benefits

  • True matrix org, with no middle management or authoritative layers
  • Focused on the products’ success vs. team glory
  • Engineers will focus their efforts in building great products & experiences, and not in pleasing their bosses
  • Engineers need not be in a dilemma about who to listen to — their line manager or product manager

Cheers!

7 Life Lessons Learned From Product Management


 

Life Lesson

Product managers apply a lot of life lessons into their job, but not many are aware that we start using a lot of our job traits in real life inherently.

Here’s some of them that I have made use of.

  1. Ruthless Prioritization: Prioritization is a key aspect in product management. It ensures the company is investing in the right set of features for maximum ROI.
    • This trait helps us product managers in real life in ensuring we prioritize the right tasks that benefit us, our family, and our society in general.
  2. Efficiency: Tactical aspects of product management involves completion of tasks efficiently and in an optimal manner, so more gets done in a shorter time and with quality.
    • Back at home, this trait helps us approach everyday chores, such as buying milk & vegetables, and even watching TV, in a calculated manner to ensure there’s less waste of time, money, & energy.
  3. Work like a team: Product managers cannot survive without a team that helps them visualize their vision.
    • Our life is no different. We need supporting people in life, be it our parents, siblings, spouse, kids, or friends, and we always understand the interests of these groups of people before taking decisions.
  4. Respect everyone’s inputs: Great ideas come from everywhere and product managers keep their ears open always.
    • We cannot ignore our close aides, family, or well wishers’ thoughts and inputs. Regardless of whether all the inputs get materialized, it’s important to give an ear to those inputs.
  5. Say no, with justification: This is one of the toughest tasks for product managers, especially when the request is from CxO.
    • In life, we always deal with people who are not at the same level of thinking as us. We deal with people with old school thoughts, immature/novice folks, and sometimes that high IQ lady. It’s with great challenge we have learned to deny some requests and with appropriate reasoning.
  6. Be available whenever needed: As product managers, we are required to be available to other teams almost all the time during business days, and at sometimes during holidays too.
    • Needless to say, we are just a phone call or message away to our near and dear ones.
  7. Motivate people around: As product managers, we constantly motivate the development teams so that they could churn out builds with high velocity.
    • Back at home, we appreciate several people. Our mother for great food, our father for timely advice, encourage kids to study/play well, and even the maid for a service well done.

When Product Managers Get Trapped…


How many of us product managers have been in this situation — trapped in an organization, an organization that does not understand the essence of product management.

An organization where:Trap

  • Product managers are responsible for clerical tasks and book keeping
  • Product managers are required to project manage
  • Product managers are made the scapegoats for engineering failures
  • Product managers are required to double up as functional managers to cover up for poor engineering managers

A few of us would certainly have some experiences to share.

If at all, we end up in such a trap, here are some tips (read as arsenal!) that could be used in times of need, so that organizations/leadership-folks understand the need for product management for product and overall business success.

  1. Data – make use of data and unearth insights about product usage patterns
    • This will make the leadership team feel the need to improve product design
  2. Competitive Landscape – research into your competitors’ products and identify gaps in your offering
    • This will surprise the leadership team
  3. Market Trends – research your target market segment and identify unmet needs
    • This will enable trust with the leadership team
  4. Feature Prioritization — effectively prioritize your features using a good tool
    • This will delight the leadership team
  5. Portfolio Analysis – do an analysis of your company’s product portfolio and let leadership know about products that need investment vs. the ones that need to be killed
    • This will give sleepless nights to the leadership team, for good:-)
  6. Product-Market Fit – constantly pursue the leadership team to understand achieving product-market fit sooner than later, because faster product-market fit will ensure the product will enjoy maximum differentiation for a longer period of time

Hope you liked the post. Would love to hear your insights too!

Feature Prioritization *New*


Back in 2011, I made this blog post on prioritization of product features, and the prioritization template looked like this.

Over the years, I have been updating the format and refining it to ensure it articulates the objective prioritization and shepherds the product towards product-market fit — the latest is here.

In general, features will have to be categorized into three backlogs. The backlogs have been named by lifting NBA terminology for self explanation.

  • Offensive Play — features that aid revenue generation and acquire new customers
  • Defensive Play — features that aid in delighting and retaining existing customers
  • Time out — features that aid cost cutting such as those that reduce product returns, reduce customer service costs, improve operational efficiency, tech deprioritizationbt, etc.

Product Managers will have to ensure appropriate ‘plays’ are adopted depending on business needs, including a mix of features from more than one backlog in a release, for creating customer value, generating competitive advantage, and delivering profitability.

Few takeaways:

  • Strike the right balance between offensive and defensive plays
  • Features that can be implemented in a shorter time are *not* always the ‘right thing’ to do
  • Always look at relative priority and the objective impact a feature will have on customer value, ROI, and overall purpose

Would love to hear what’s on your mind!

Is MVP the right approach for launching consumer products?


I’ve come across many people, particularly UX designers:-), growling when they hear the word ‘MVP’ (acronym for Minimum Viable Product) — it’s because some of their favorite features/designs get missed out.

Most people think MVP is just a bunch of features that are being planned for the first release of a product/solution or just another scoping exercise. Some of the traditional definitions too confirm that thinking.

  • MVP is a set of minimum features, a minimum feature set
  • MVP is a feature set that allows the solution to be deployed, and no more
  • MVP is a set of features that ‘can be’ delivered by the expected date
  • MVP is a set of top features that users asked
  • And so on…

On the contrary, I believe MVP needs to be conceived with a 360 degree perspective on how the initial offering will benefit customers and stakeholders. And of course, within budget and schedule constraints.

To summarize, an MVP needs to:

  • epitomize core value proposition with the right mix of features/experiences
  • justify ROI vs. risk
  • help determine user acceptability of the offering
  • help identify demand for specific new features
  • promise great new things ahead

MVP

Would love to hear other insights and feedback!

Motivating Development Teams


I bumped into this article almost a year ago, and it’s only now I’m finding time to blog on it.

http://www.mironov.com/motivating/

Great thoughts there. Following are some of the things I’ve practiced and they work well.

  • Inform the team about the product demonstrations you conducted and how much the audience appreciated their work
  • At every opportunity, give them the feeling that they are great developers, specifically in sprint planning and product demonstration sessions
  • Reiterate the impact some of the features will have on customer experience, product ratings, and on the overall business
  • When junior developers think in similar lines to that of their seniors, point it out to them and get them excited about it
  • When giving suggestions for technical design or product scalability, always end with the note that they can come up with something better
  • Never make them feel bad or low about some obvious questions they may have
  • Take them for lunch or dinner at opportune times
  • Crack jokes at opportune times (even recycled jokes work!)

Do share what you do to keep your development teams motivated!

UX Driven Companies vs. The Crazy Ones


It’s been a while since I blogged — life is too busy with fire-fighting drills. Now, back to blogging and this time let’s discuss about User Experience or UX as it is widely referred to.

UX is the lifeline for consumer companies specifically that are into lifestyle based products. In spite of this, some companies (if not all) do not give the significance it deserves. UX planning is just not in the plan.

Some of the reasons for this could be:

– the leadership team does not understand the importance of user-design driven products

– engineering teams’ upper hand

– helpless product managers (caught in bureaucracy)SuccessQuote

– voiceless UX team (bureaucracy again)

– spineless project managers

– casual approach to real user feedback

– inability to separate noise from real user feedback

– everyone thinks he/she is a designer and that their feedback needs to get implemented (more on this here)

– attempting to design for everyone, ignoring the targeted personas

– internal politics

How much significance does your company give to UX, or is UX just another ritual? Would love to hear from you.