On Working with Senior Stakeholders

This is the one single thing that can really expedite your growth (or obstruct it) in your corporate career.

Working with / Managing senior stakeholders is difficult. Really difficult. And PMs ( even junior ones) have to do it all the time.  Have gone through a lot of mistakes myself and I am still learning, but here are a few things I have learnt on the way –

Establishing a relationship at the beginning

When you begin working with a senior stakeholder (could be your own boss, head of a function/ CEO) – that’s the time to make a good start and set yourself up for success.

Get to know them

half the battle is won if you can make a tailor made approach to working with your specific stakeholder.

  1. Check their linked in
  2. Read their blog if any
  3. Ask specific questions about their background (whenever you get a chance to meet over a social event/ whenever you see the right opportunity)
  4. Understand their current role and challenges.
  5. Understand their goals/ objectives: this will help you talk in terms of that, present your case in those terms and work backwards to craft your messages.
  6. Understand their working style – do they prefer daily updates / or once in 2 weeks ? It is ok to ask what works for them, how to best utilize their time.

Introduction meeting / First few 1-0-1 meetings.

If you haven’t, please go ahead and setup a proper intro / 101 meeting with your stakeholder and try to accomplish the following –

  1. Introduce yourself & your strengths – this would make your stakeholder develop an initial confidence in your capabilities and talents. You may / or may not get 30 mins to talk about your background – but you would need to find opportunities to demonstrate / talk about your past and strengths you derive from it.
  2. Request an introduction: When you have introduced yourself, you can say something – “would be great if you could share bits of journey too” and let the stakeholder talk. Ask questions – show your genuine interest in his /her experiences and interests.
  3. Clarify expectations – by discussing them openly / what are his / her expectation from you and your team (if any).
  4. Negotiate the support you need – be clear about what would work best for you and what wouldnt. Would help you set the right expectation.
  5. Find common interests on which you can spend time and build personal rapport.

Delivery / Work related Meetings

Prep

  1. Make sure you have the right understanding of the agenda before you head into the meeting.
  2. You should take these meetings as performances. Prepare your inputs well.
  3. Think of potential battles/ questions that would come up. Prepare your responses in advance.
  4. Know which battles you are ready to lose and which ones not.
  5. Try to present in a way that battles you are ready to lose come up first and then the difficult ones which you don’t want to lose. ( this is a very tricky and takes a lot of practice J ).

In the meeting

  1. Set expectations to begin with – that you would be presenting a summary and then the details.
  2. Start with a quick 2-5 min summary- so that the impatient senior stakeholder gets it one go. Getting straight to the point is super important.
  3. Follow up with details
  4. Listen Well.
  • This one is hard and takes a lot of practice. Try to see things from the other person’s perspective.
  • Go beyond words and try to understand their real problem.
  • Observe body language, observe indirect signals.
  • Proper listening is a study and science of its own – pay attention to this one.
  • Be open to feedback. Don’t defend too much.

5. Answer Well –

  • As directly and briefly as possible. Don’t try to provide too many details, unless asked for. Senior Stakeholders are insanely busy & a bit impatient to get to the answer they are looking for. So get straight to it.
  • Don’t provide an answer if you aren’t really sure. Ask for time if required.

Growing the relationship: Build & Preserve Trust – single most important aspect.

Over time, there is a reputation / image your stakeholder will develop about you. This is the one thing that would decide your future opportunities / role / growth in the company.

  1. Keep Promises
  2. Don’t Overcommit
  3. Be responsive to their asks / emails / phone calls.
  4. Do frequent check-ins to stay in sync / ask feedback / share feedback (when possible).
  5. Demonstrate your competence when an opportunity arises.
  6. Demonstrate high level of integrity – take responsibility for mistakes if any and show steps to fix them. Continue to work on the highest level of rigor.
  7. Share updates when you know that they can be useful, even when no one has asked. This helps stakeholders develop a sense of confidence and transparency.
  8. Last but not the least, build your personal rapport – Don’t miss opportunities to travel together. Colleagues can be made friends outside the office (not inside).

 

Do remember that beyond a point functional skills don’t matter as much, soft skills do. So take this one really seriously and share your experiences and feedback too

Parting thought – Working and building relationships with senior stakeholders is hard work, effort needs to be put right from introduction to every meeting as well as casual meetups over lunch / travel. Plan this time as an investment into the growth of your career.

Resources

Advertisements

A Robust Framework for documenting / reviewing Product Requirements

Thanks to Philip for his feedback on my previous post on design, this is a post dedicated to documenting & reviewing Product requirements.

I would recommend this article for professionals in business (Marketing, Sales, Operations) as well as  Tech ( Product, Design & Engineering) Functions.

Background 

All of of us in the tech domain want to build more meaningful products, that solve the problem at hand, move the intended metrics and do so in the minimum possible time and effort, maximizing the ROI.

The responsibility of making the above falls on the Product Manager, Engineering Lead and the Design leads of a Product. I personally believe in the “PM  = CEO of the Product” philosophy and hence I expect a LOT from the Product Manager.

If we were to imagine that the Product Manager is running his own little startup, I prefer looking at engineering & design bandwidth as her limited reserve of funds / capital.  She rather plan the bandwidth spend very very judiciously or bear the consequences of a failed product / poor ROI on her team’s efforts.

Managing Priorities &  Defining requirements for the right product capabilities are her biggest responsibilities and deserve a LOT of hard work and attention. Of course both of these activities need a bunch of activities to happen like user, market research, interviews, observing metrics, insights, trends etc. but the ultimate goal is to move the intended metrics with the help of building the right experiences and tech capabilities.

Managing Priorities: 

Have made a few posts in the past on Macro and micro level prioritization.

Defining Requirements

Requirements take a lot of time define properly and all of us try to take shortcuts and want to get stuff out faster, this is where its important for the reviewer to make sure that the shortcuts (if any) are well acknowledged and risks understood and if the given product / feature is really critical from a business standpoint to get right in the first or second iteration – you better do your homework properly.

High Level Process Workflow

Its 2 broad stages –

  1. Concept Definition & Validation stage
    1. Goals,
    2. Metrics,
    3. Users & Use cases
    4. Concept.
    5. Review and validation of the above with business / users and collaboration with engineering & design teams.
    6. Make sure you do thorough reviews at this stage to make sure any obvious issues are caught early and both engineering and design teams contribute and align on the high level approach.
  2. Product Requirements Detailing stage
    1. Scenarios
    2. Stories
    3. Designs (wherever applicable)
    4. Future thoughts
    5. Cross Product / System Impact Analysis Checklist.

Lets go over these one by one.

Element #1 – Goals (Elevator Pitch)

  1. This is where your interviews with your business stakeholders / users/ analysis of the data would come into play.  Feel free to quote the user pain points & data points that makes the business case.
  2. Business Goals: define the expected business outcome/ business objective to be met.
    • Goal 1  – <140 characters>
    • Goal 2 (if any) – <140 characters>
  3. User Goals: Define what user problems are to be solved.
    • Goal 1 – <140 characters>
    • Goal 2 ( if any) – <140 characters>

Element #2 – Success Metrics

  1. Define the top 1 or 2 metrics you would like to see moving.
  2. NOTE: whosoever is the proponent / champion of a particular feature or product should take a stab / be convinced with the projected metric movement. For example – if the PM is pushing for a particular new fancy shopping cart experience for her B2C product – she should down put down a metric movement number she feels confident about, similarly if its a B2B use-case where certain efficiencies growth is expected – the business user should help in identifying the projected improvement.
  3. This is a very critical exercise, sometimes doing this exercise pushes a previously important looking feature down down in the priority list.
  4. Put down the current state of those metrics and the expected future state.
  5. Tip: Make sure you a metric thats closest to revenue / cost (if not one of them). It might be one level or 2 levels down from Revenue / cost but not too deep. Picking / targeting the right metric brings a lot of clarity for the entire team collaborating on this Product / Feature.
  6. Potential Template –
Which business metric should move ?
Current state of this metric (before go live)
Expected state of the metric (after go live)
Comments/Assumptions
<Metric Name 1>     Example- X dollars / month  Example – Rise by 20%.  
<Metric Name 2>   Example- Y mins / session  Example –  Rise by 30%  

 

Element #3 – Users and their use-cases – today &  tmrw.

  1. This is a mix of 3 things – identifying the list of your users, what do they do today and what do we expect them to do at a high level tmrw if were to solve their problem.
  2. Your thorough user research should get captured here.
  3. Here is a potential template
User
Current Use-cases
Expected/ Future Use-cases
Camera Buyer (on an online camera buying platform)
  1. Searches for x’
  2. Finds ‘y’
  3. Makes a list
  4. Remembers their specs in his/ her mind or copies them into a separate excel sheet
  5. Compares – alpha, beta on the sheet / in her mind
  6. Finally buys y.
  1. Sees comparison of various models on the screen where she discovers ‘x’
  2. And / Or adds other models into the comparison bucket
  3. Opens the comparison bucket
  4. Finally buys y
User Type 2 (Say camera curation/ reviewing team)
  1. Tasks 1
  2. Task 2
  3. Task 3
  1. New Task 1
  2. New Task 2
  3. New Task 3

 

Element #4 – High Level Concept / Flow Chart

  • Put down a flow chart / designs on a paper / a few sentences that explain the concept / high level solution on paper and get that validated from your users.
  • This is where a lot iterations happen. Time spent here, saves a lot of it afterwards.
  • From a documentation perspective – Flow charts do a good job at this stage.
  • If you can come up with Concept Designs, that would make it even easier to do validation. Invest this effort depending on the nature of the feature.
  • Tip: LucidChart is a decent flowchart authoring tool and has simple JPEG and PDF exports available 🙂

 

Element #5 – Detailed Scenarios

  • I was not a big fan of this. I thought Dev/ QA doing this job should be sufficient, but have been proven wrong on this one.
  • These are nothing but various scenarios including negative and positive user actions, various entry points, various diversions on a user flow etc.
  • These scenarios would help the PM / team come up with an elaborate list of stories for the next section. Feel free to take Dev and QA help here.
  • I have come across situations, where an entire solution gets redesigned because of one missed important scenario 😦 , so highly recommend putting in this effort.
  • Sample template

Scenario

Expected Behavior

What happens when the user abandons the journey in the middle and returns tmrw ? 

What happens when he lands on this page without logging in and after logging in ? 

What happens if he types in in-correct mobile number by mistake ? 

 

Element #6 – User Stories 

A lot is available online on this one, here are my preferences –

  • Follow the format – As a <user>, I want <feature> so that <benefit>. Clarifies the feature context to everyone.
  • Break it down to specific sub-functionalities so that each story is fairly small and is independently deliverable / shippable (more or less).
  • Go into details and make it easy for engineers to understand. Don’t leave the stuff at a high level – going deep helps.
  • This is where you can add a sense of priority too.

Sample template

S.No.

Story Title

Details

Priority

1

As a user I want to login to see my emails

Elaborate and provide details about each of the basic acceptance criteria 1) Login 2) Log out 3) Forgot Password 4) Session Expiry ..etc.

High

1

As a security office, I want all users password to expire after 90 days so that password theft impact is mitigated.

Call out expiry details

Medium

 

Element #7  – Designs ( if applicable)

  • Having a hi-fi Prototype, tested on the ground is the ideal state on this one. Very hard to achieve though.
  • Wireframes are a bare minimum.

Element #8 – Impact Analysis Checklist

This is especially relevant if you are working with multiple systems that interact and depend on each other, impact of one tiny change in one system might break / have an impact on the other.  For example, a small change in the search ranking algorithm on an eCommerce portal might directly impact the earning / profits made by 3rd party sellers.

Its better to make a list of systems that are usual suspects for a particular system and make sure you have thought about each o of these while designing the above solution.

The reviewer of the document – should apply his / her own lens to ensure all the impact has been covered / thought out.

Sample template –

PRD Completeness Checklist

S.No. System / Activity Covered / Thought Through ?
1 Analytics / Tracking into Web Analytics  Yes
2 Impact on system ‘x’ Yes
3 Impact on System ‘y’ Yes

 

Element #9 – Future Thoughts

  • This section helps in capturing all future version thoughts. Provides an insight into the future for all the stakeholders and also forces the PM to define an evolution path for the given investment.

Additional Notes/ Resources

  1. Ballpark estimates – Getting the concept in place helps design and engineering teams with estimates that are so crucial for longer term planning
  2. Thinking about Go To Market / Post Go Live right upfront also helps a lot.  For example a nice cool feature doesnt help in creating PR if its hidden too deep inside. May be having an option to explore the nice cool thing on the home page might help.
  3. Here is a slightly dated & but an excellent post on coming up with meaningful product requirements by the Guru himself   – Marty Cagan on writing Good PRDs. 
  4. Update Marty Cagan’s previous post.

 

A Framework for doing UX design reviews

In today’s world, guess its well understood how important is designing your products and experiences in right way.  Having understood this importance, most companies hire designers/ outsource the design process. Some still have PMs / Engineers / Marketeers  making product designs.

In any scenario, the process goes through an initial concept of an idea to paper wireframes to more detailed designs (wireframes and then visuals). And then we go through iterations on each step.

Also, specifically whenever we (as Product Managers / or other stakeholders) sit down to review interaction designs / wireframe / visual designs or anything post the initial concept stage we tend to think about a lot of different perspectives, this is exactly when we also tend to miss out certain elements of the design that need a lot attention.

Its for this purpose, I have put down a checklist / framework for reviewing such designs, just so that all feedback gets captured in fewer iterations.   This by no means would be comprehensive, in fact would love to hear your feedback on which important aspects are missing so I could them in.

Also, while making this list, I have borrowed heavily from this excellent book on UX.

  1. Persona / right frame of mind: Get into the persona and frame of mind of the user. Make sure you spend some-time thinking about this user (say half a minute or so) before you start reviewing the design from that users perspective.
  2. User Flows – Its important to review user flows instead of just screens. Most of your screens would be common – but its the user flow that would give you the questions the screens need to answer.
    1. Call out the flows /scenarios to be played while reviewing the design
    2. And then take each scenario and run through the screens
  3. The Strategy Plane: business & User Objectives
    1. Does the screen communicate what it is about and what action is required by the user ?
    2. Heading
    3. Sub-heading
    4. Overall message being conveyed by the screen in the first glance.
  4. Scope Plane: Functions & Content
    1. Go over all the questions the user would have in his mind and whether the screen provides answers to those questions. This would need you to make a list of questions that would pop-up in the user’s mind when he looks at this screen.
    2. Review Sections & Sub-sections
    3. Review the functionality and content of the screen
  5. Review the CTAs
    1. Identify the primary CTA(s) of the screen and make sure its easily visible and attracts the most attention on the screen
    2. Identify the secondary CTA on the screen and takes lesser attention than the primary CTA and is still fairly visible as per the business needs.
  6. Structure Plane: Interaction Design & Information Architecture
    1. Screen specific Interaction elements
      1. effectively communicates interactivity and functionality(what user can do).
      2. informs user about state changes(file has been saved, or any feedback), while they interact.
      3. prevents user error or mistakes, like the system asks user to confirm potentially harmful action(i.e. deletion).
    2. Hierarchy of information laid out on the screen and each section.
      1. organizes, categorizes, and prioritizes the information based on user needs and business objectives.
      2. makes it easy to understand and move through information presented.
      3. flexible to accommodate growth and adapt to change.
      4. appropriate for the audience.
  7. Skeleton Plane: Navigation & Information Design
    1. Navigation design –
      1. how would the user arrive at this screen
      2. Specific sections of the screen
      3. Go back to where he came from
      4. Come back to this screen after going back etc.
    2. Information design
      1. How exactly is the information displayed / designed.
      2. Text, images, icons, logos etc.
  8. Surface Plane: Visual Design
    1. Brand personality/consistency
      1. The personality of the screen should match the brand personality.
      2. This includes fonts, colors, tone of the language, button labels, headings etc.
    2. Unity, Variety and Balance.
      1. Unity – Visual Consistency in elements.
      2. Variety – Different elements marked different visual so that the user can tell the difference.
      3. Balance between Unity and Variety so that the screen does not get confusing / over-whelming.
    3. Visual overload / burden
      1. Depending on the purpose of the screen.
      2. Functional screen where users are expect to complete a task are visual light  / not-overwhelming.
      3. Where as magazine type use-cases where the users are just expect to browse, the screen should be visually interesting to look at.

This can also be used by the designer to make sure he/ she has thought through all the aspects of the designs and hasn’t missed out anything important.

Resources:

After I have started to refer to this list, it has started to take a lot more time reviewing the designs, but a lot of detailed feedback has started to come out, hope you find this list helpful too. Do share feedback.

 

Next Post: (Should have ideally published before this one 😉 ) Framework for documenting and reviewing Product Requirements.

 

Product Mgmt for newbies #7 – Prioritise your time, learn to let go.

One of the biggest challenges I had when I moved from engg to Product was this – I started a lot of activities / tasks and couldn’t finish them. This felt bad. Sometimes when I tried, I ended up finishing tasks that were not that important any more. That felt bad again.

Lesson #1

Slowly and painfully, there was no option but to be okay with letting go of half finished tasks. Take a deep breath, let it go and focus on the most important activity.

 

Especially in a role where there are no well defined daily / weekly targets.

As a PM there are a bunch of activities you can potentially do/ get involved in:

  1. Gathering customer feedback.
  2. Converting that feedback into Product solutions/ enhancements.
  3. Discussions with design team on various open design issues w.r.t your product.
  4. Various different kinds of discussions or meetings with the engg team  (
    1. Estimation / feasibility feedback on an upcoming ambitious project.
    2. Backlog grooming
    3. Sprint planning
    4. Daily Standups
    5. Demos
    6. Retrospective meetings.
    7. UAT testing
    8. Clarifications to QA / Dev team members on various on-going activities.
  5. Discussions with different stakeholders on their pain points.
  6. Discussions with your boss(es)  / top mgmt on current issues / future plans
  7. Meeting with Product Marketing / Sales Teams on upcoming partnerships / dealing with competition/ upcoming marketing campaign.
  8. Studying competition/ reading latest consumer reports.
  9. Following tech news for new possibilities and use-cases that could fit your product.
  10. Prioritizing next week / month’s backlog items.
  11. Detailing our requirements for the upcoming sprint.
  12. Program managing cross functional deliveries.
  13. Client/ partner meetings where you are involved as a Product Expert.
  14. Meetings / demos with new vendors who could help you measure your product usage better.
  15. Studying metrics and analytics/ digging for patterns and insights.
  16. and the list is endless..

 

Product Mgmt is not a very well cut-out role, the boundaries are usually blurred, the expectations are not crisp, the control you have is limited. Its extremely easy to slip into doing things which are not going to get you the outcomes your business / product needs.

For you to be making an impact you need to be cognizant of where your time gets spent..

Lesson #2

Spend some time every fortnight / month thinking about what exactly did you accomplish and deliver. Were you satisfied ? Yes – great. No – see where you could have saved your time.

 

Lesson #3

Another habit / trap was to start doing things with which I was comfortable with. Tasks that were easy. I think I still sometimes fall into this trap. Too bad. Not effective. Face the important tasks head on. Don’t be afraid. Go in the unchartered territory & get some results.

 

To summarize:

  1. DO NOT get swept away with the barrage of distractions and requests you get every day / week. Decide to spend your time consciously.
  2. Learn to be be okay with un-finished tasks. Control your urges to finish lower priority tasks and to get addicted to the dopomine high you get on finishing them.
  3. Learn to attack the important tasks even if you have no idea how to do them. Control your urge to do the easy stuff first.
  4. All of the above are hard. But keep trying 🙂

 

Product Mgmt For NewBies #6 – Think Metrics

Have you ever measured how much time do you spend having coffee / tea breaks or having random water cooler discussions / sutta breaks with colleagues ?  Have you measured how much do you spend checking / responding to email ?

I had taken a stab at measuring these back in 2008 and I had realized I was spending just way too much on them. A few days of measurement helped me improve my productivity and time spent in office tremendously. I was trying to measure and improve my productivity as a software developer, that was also when I took a series of steps to improve my productivity using little tips and tricks (published quite a few blogs posts too on the topic).

There is a famous saying, “you cant improve what you don’t measure”.

When building a product/ feature, the idea is to move some metric. What is that metric ?

Your users ability to accomplish a task ?

Your ability to make money from them ?

All objectives can be defined in the form of a metric and can be measured.

And yes, keep in mind there are LOTs of metrics you CAN measure. Does not mean you need to measure/ focus on them all.

Define the objectives & focus on the key metrics.(Top 1 or 2 metrics only)

Its extremely easy and usual to get lost in a barrage of metrics. Page views, bounce rate, exit rate, conversion rate, click through rate and a thousand other metrics. But you need to very clearly define the objectives of a product and just focus on the top 1 or top 2 metrics at any given stage of the product / company.

  • For example, at product launch, the key metric to measure might be the # of users doing the first step or the first few steps after installing the app  – essentially answering the question whether the users are able to see value in the app to invest the time for those first few steps ? Is your app’s on-boarding experience appropriate ?
  • Next phase could be to measure how many users are taking the key step of accomplishing the task that the product was designed to do. For example, for Practo, it would be whether users are calling the doctor / scheduling an appointment with the doctor they were looking for ?
  • The following phase might be whether users are coming back after the first use ?
  • And so forth.

After a point you might be measure a combination of the a few metrics ( the top 2 metrics I referred to.). But restrict yourself to a max of 2. Do not go beyond that. They are a distraction. ( There are enough distractions in a PM’s life anyway)

Feel free to measure and go through a 100 metrics for sanity purposes. To ensure that nothing is completely broken / has a bug. The idea is to focus your time on moving only the top 1 or 2 metrics.  

Feel free to setup alerts for several sanity metrics.

Just so that you don’t end up wasting time going over all the sanity metrics you can setup alerts so that you get an email when there is something abnormal. ( like # of users in a particular segment of users, or the usage rate of a particular important feature etc.)

Here is how you can do this on Google Analytics. Having these alerts in place will give you a bit of peace of mind that someone is checking them every day / week so you can focus on the other stuff.

The top 1 or 2 metrics will also ensure alignment and help you take trade offs.

Your boss / peers / engineers / designers  and all other stakeholders. You might be chasing a different metric and your boss might be looking at a completely different one. Align yourselves on metrics and not features.

When the discussion is all about that top metric, its much easier to take those trade offs while designing  / architecting a feature / system.

When planning/ prioritizing a feature – try to predict how much change do you expect to see in the top metric.

This will help you prioritize. A feature that’s cool and the latest in-thing but will not move the key metric does not deserve attention at that given stage. This will also help you improve your product judgement about what product change brings about how much change in the key metric. Key to being a successful PM. Its calculated bets you take after all.

Master Product Analytics tools 

You wont believe how effective you can be in your decision making if you knew how to make use of Google Analytics / Localytics / Mix Panel or whichever Analytics tools you use.

There are tons of video resources available on the internet to help you learn. Spend your weekends on them. These tools are going to be your bread and butter. You HAVE to be master. You have NO choice.

Caution: Don’t be too obsessed by Quantitative Analysis, Qualitative study is equally important.

Many folks believe that quantitative data and Analytics tools like Google Anlaytics etc have all the ‘insights’ they need. I strongly disagree. There is no better alternative to actually seeing your products being used by real users. (Whether you see them face to face, or you see recordings is your choice).  I have said this many times, metrics/ analytics are symptoms of a problem / behavior, the root cause is usually found when observing / talking to your users. So please do talk to your users as often as you can ( 1-2 times a week is a good number).

Useful Follow up Resources:

Would love to hear your thoughts  / feedback on the topic.

Prod Mgmt for Newbies #5 -Understand your business holistically

In one of my early days as a PM, when I talked to people about making more money, I always used to say build new products. Sell them to existing or new customers and make more revenue.

I was so wrong and limited in my understanding of a business.

Understanding one’s business in-depth is extremely important for a Product Manager for him to take the right decisions given a business objective.

Understand your business

Here is a basic list of questions I would suggest you to ask yourself and your peers/ leaders:-

  1. What do we sell ?  ( do we sell experiences ? physical products ? Phone numbers ? )
  2. Who are the customers and how do we acquire them ?  (understand the acquisition strategies we use)
  3. Who are our suppliers and how do we acquire them ? 
  4. How do we grow our user / customer base ? (On all sides of the business)
  5. What generates the most revenue ? Or rather whats the revenue split by user / product segments ? ( iPhone generates the most revenue for Apple, did you know that? when there is a conflicting priority between Mac and iPhone, you know which way Apple is going to go.
  6. What incurs the most cost ? Or better if you can get a high level split of the costs.(Many companies have Marketing as their biggest cost, for some its RnD, for others it might be operations – you need to understand the split)
  7. Who are our competitors ? And how are they different ? 

When I started to develop an understanding of the above, I stopped saying build cool new products, my thought process on making more money started to bend around expanding the customer base, or increasing pricing by offering a premium feature on an existing product, or monetize an existing asset which we are not monetizing today..or automate some aspects of the business to increase profitability, or may be just optimize a particular flow in the product to increase revenues.

Why are certain new products built/ sold ?

Next, lets try to understand why do companies build the products they build, or features they add.

  • Why do you think Google built Google Chrome ? To provide a better browsing experience to the world ? To make websites faster ? Think again.
  • Why do you think Amazon built Kindle ? To provide next generation book reading experience ? No. e-Book readers already existed in the market. Think again.
  • Why do you think Google is building project Google Loon and Facebook is trying to provide free access to Facebook ? To help people get access to internet and improve their lives ? Not exactly.

All these products are built to help the company

1) Acquire new customers 

  • Google chrome search bar leads to more google searches. Hence more people see/  click ads. ( and hence more money)
  • Kindle leads to more people buying books from Amazon. And seal the existing ones  to amazon forever.
  • Google loon / FB free access – would provide internet access to people. What would those people do ? Search for stuff on google or browse content on FB. Hence more ads and hence yet more money.

2) Strengthen their current position/ assets.

  • If one gets used to using google chrome and searching from the search bar on top. Google’s position as a search leader is further strengthened.
  • Amazon’s position as the biggest online book seller gets further strengthened.

 

Why are companies built ? Why do companies exist ?

Two reasons

  1. Solve a user problem / fix an inefficiency in the system.
  2. Make Money. For most companies, #2 is all that matters.

So don’t just think that a new cool product is going to solve a real problem and stop at that. Think money too. Make it a part of your habit.

Useful Resources & Parting thoughts

Product Mgmt for newbies #4 – Start small / trim to the most imp. use-cases

When I first took up the PM role, my first assignment was to make my product stable & bug free. It was a B2B product being used for a high stakes client supposed to generate quite a bit of revenue and establish company’s reputation with the client and win more business & client for us.

Now stability, you might think, is engineering team’s role. But I wouldn’t say so.

Why do smart phones have more bugs, than the old simple feature phones ? Because smart phones have a lot of features. The more features, the more the complexity and thus more bugs are obvious.

I made a list of features my product had vs which ones were REALLY business critical in the MVP stage and trimmed out / cut down stuff that wasn’t critical at that point.

Ideally, one should decide the list of most important features by looking at product usage data and if thats not available, then try to prioritize the requirements you have understood by talking to your stakeholders ( including users of the product). Here is a really good article on feature audit by intercom.

After that ruthless trimming the product became a bit less complex and easier to change & manage. It took us 3 months of trimming, testing,  simplifying to get the product to a usable state.

After that, we added only those features, which were the most important and REALLY required for the user/business.  Sometimes, we mis-fired and added a complex feature which wasn’t used as much. Regretted that. But keeping a very close watch on number and nature of features you add is extremely important.

Don’t make  / keep your product complex to the point that it becomes very hard to manage or use.

There are several reasons why the Product backlogs are overflowing with features/ tasks / bugs.  This being one of them.

So while planning your roadmap / your MVP, learn to say no. Learn to argue. Go by data. Go rock !

PM for Newbies – #3 – clearly understand what value PMs bring.

Many times, people ask me, what is it that a PM does. There is a business (operations / marketing /sales) guy who run the business, there is an engineering team who build the product, so what exactly PMs are supposed to do.

And this great post by Marty Cagan at svpg helps me answer that question. Go ahead and read it.

Quick summary

  1. Deep understanding of the user
  2. Deep understanding of the business
  3. Deep understanding of the industry /competition.
  4. Reference Customers
  5. Motivation

So what should we do ?

  1. Users: Talk to users at least twice a week. Try to understand what their problems are, what their behaviour is etc. There is quite a bit of literature on on how to do user interviews on the internet. Tip: This video is nice. If you do not talk to users that frequently, you are going to assume a LOT of things about them. Don’t let that happen. Take data driven decisions. Google Analytics and other analytics is nice, but nothing beats qualitative direct user feedback. I would even argue that the analytics data is like symptoms, in most cases, you wouldn’t see the root cause, unless you talk to users.
  2. Business: Spend time with folks in other non-tech functions – Marketing, Sales, Finance, Operations. This would be give you a solid edge in your job. No other function would know so much about your business as you would if you spend time with each one of them. Park, say an hour, every week for this one. The ROI here is going to far bigger than you can imagine. I have done this mistake of not spending enough time outside of my focus area with other functions & I regret it ! (Even the ones I do not necessarily need to interact with for my product – have been very enlightening and helpful). So please don’t think of this as a low priority, nice to have task in your list. This is as important as your sprint planning meeting.
  3. Industry: Study your competition, follow blogs and news about the industry. But do not spend too much time on it. Spending an hour or two once in two weeks is also fine. This can drain a lot of your energy. So just be judicious on this one.

But be very clear, if you are not doing the above, you are going to take very sub-optimal decisions. The core job of a PM is to take the right decisions about the product.

So do get out of your comfort zone, make a bit of discipline and build awesome products !

https://pankajghanshani.com/2016/04/04/pm-for-newbies-3-clearly-understand-what-value-pms-bring/

PM for Newbies – #1 – Whats your problem?

WhatsYourProblem

As a way to learn myself (by sharing what I have learnt 🙂 ) , I am going to make notes on all my key learnings as a Product Manager.

So I am starting this series today and I am going to organise into the following categories — Newbies, Business & Finance Intelligence and Product Management general practices.

Here goes my first post for Newbies —

Understand the ‘Problem’ . Define the ‘why’.

Many times early in my career as an engineer / developer, we used to talk about solutions. Cool Features. Cool new technologies.

Not problems they were going to solve.

Define the problems and make them the most important guiding light. It could be problems of a user segment, or specific business problems. These problems should guide the solution.

Why ?

If you are very clear about the problem, comparing solutions would become easy.

Calculating ROI (return on investment) of a particular solution is going to be easy.

Validating the solution is going to be easy. You can ask/ validate whether this solution is solving the original problem you set out to solve.

So, very very clearly define the problem a product / feature is going to solve.

Your solutions might keep changing but the problem wouldn’t / shouldn’t unless its not a valid problem at all.

How ?

Step 1: Talk to people. Become a user yourself.

When you talk to people, they wouldn’t usually tell you their real problem directly. So talk to a lot of people and make your own notes on what is underlying common theme. Whats the underlying real issue at the symptoms people are describing.

Hint: Empathizing with users and the ability to get into their shoes is a key skill you would need. (So work on that.)

Step 2: Then write your conclusion about the problem down. Validate that written definition with the users.

Step 3: If users agree, you now have a defined problem. If not, go back to step 1.

And next time if you have to compare two existing apps in the market, or two solutions, don’t compare their features, compare how well they solve a given set of problems in their order of priority.

The Single Most Important question for Product Leaders

I think this is the single most important question for Product Leaders:  What would you do next for your Product ? Which feature / feature set would you prioritize ?  If you are senior product person / a PM with a large product portfolio, you would know that many of us get lost in day to day deliveries, stakeholder mgmt, customer requests and the ten thousand other things that PMs are supposed to do and in such a situation its easy to lose sight of big picture.

( Thanks to Dilbert :))
( Thanks to Dilbert for the image 🙂 )

I suggest that we first understand and build the larger context around the Product and then the feature prioritization process would become much easier.

  • Organizational Direction : 
    • What is the direction of the company ?
    • What role does your Product play in the future direction of the company ? 
    • Whats the current purpose of your product for the company?  Revenue ? Cash-flow ? Profits ?  Customer Acquisition / Marketing ? 
    • Is your Product able to fulfill that current purpose very well ? What are the gaps / strengths ? 
  • External View:  
    • How is the competition ? 
    • What is the future of a product like yours ? Where is the industry going ?  (think what happened to digital cameras when phones started to ship with Cameras, think what happened to Data center Mgmt companies when a huge part of the world moved to the cloud etc.)   
    • How do your customers use and perceive your product ? ( Are they happy ? For what reasons etc.)  
  • Execution Abilities & Constraints.
    • How much risk appetite you have in terms of spending money / engg bandwidth ?
    • How much time do you have in your hands ? Whats the urgency ? Can you start on something that would take 3/6 months to build ? 
    • How much engg capacity you have ?
    • What are the engg teams strengths ? 
    • Where does the organization stand in terms of other required organizational capabilities  ( that are important to your product / features’ success)? Like design / supply chain mgmt / marketing etc.
  • Based on the above you need to articulate your Product’s Vision, Strategy & Goals.
    • Which aligns well with your Organization’s Vision, Strategy and Goals.

Based on all of the above you should come up with the most important directional priorities (or themes)  for your Product for the next few months / quarters.

And then prioritize stuff within themes which would primarily be based on the ROI (Impact / effort) keeping in mind the factors mentioned above.

Doing all of the above should not take more than a day or two and would then make it easy to communicate those themes to your individual sub-product owners / teams.

There is also quite a bit of reading material on prioritizing features once you have the larger context figured out – check out this thread on Quora.

Would love to hear thoughts / comments / feedback.