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/

Advertisements

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.

Six things to learn from the iTunes Story

I just read the iTunes chapter of Steve Job’s bio last weekend and it just completely full of business lessons. Here are some I observed:

Background: Consumers wanted to download songs into their computer, into their iPods, and there was no easy way. Buying CDs offline and then ripping them into the computer was a bit too inconvenient. So consumers used to download using file sharing networks. Piracy. Apple solved this grave problem for the music industry, by creating a way for people to download songs legally from their computer and pay for them.  iTunes store was the solution.

 

Lessons

  1. Apple solved this problem in a way that kept the consumer in mind. Consumers could buy individual tracks from the album (and were not forced to buy the whole album). Completely untraditional.
  2. Sony was in a much better position to do exactly what Apple did, probably better. But organizational mis-alignment was a huge handicap for them. (Music and tech departments could not work together to come up with something that worked for both). Organizational mis-alignment can make you lose on huge opportunities.
  3. The pitch that Steve made when revealing the product was 1) High quality music  2) A way to try songs before you buy 3) Good karma (no stealing). Steve talked about ‘Karma’.  A sales pitch that directly hits the soul. Wow !
  4. The end-to-end integration between iTunes, iMac and iTunes was completely seamless from day 1. That says something. When you launch a product, make a compelling story.  Think through the experience.
  5. A Million songs sold in 6 days. Obviously huge success, but it also tells that Apple’s infrastructure could scale to support that kind of traction in the first week itself.  When going live and trying to make it big, keep high standards for your platform infrastructure.
  6. Microsoft and Sony tried replicating the same model with their devices, clouds, but Apple kept launching newer  & better versions of the iPod.  It was very hard for the competitors to grab a significant market share. Lesson: For product companies – the speed of innovation and delivery is the ultimate competitive advantage.

Would like to hear your thoughts on these / any other observations you made on iTunes.

A Practical Approach to prevent sprints from becoming mini-waterfalls

Let me admit. Preventing sprints from becoming mini-waterfalls is hard.nature-waterfall

There are interesting articles out there (here & here) which explain how agile sprints are different from waterfalls.

The thing is to break big requirements into small byte sized user stories and deliver a few stories in every sprint. But the essential 4 step sequence does not change –1)  Requirement Analysis -> 2) Design -> 3)Code -> 4) Test

Teams start doing these 4 steps for each story within a sprint.

Update: This is fine as long as you don’t have any new type of requirements, for which the steps 1 & 2 are significantly time taking. Or the estimates are going to be hugely different based on the design. Meaning situations where lets say a new architectural block needs to be brought it, or a major arch/ design change needs to happen.

If you do have to bring in a major change in steps 1 and 2, then there are 2 problems here:

  1. Since the requirement has not been analyzed very well and the technical design is not done yet,  the estimates for these stories are going to be highly in-accurate.
  2. Second problem is that you would want to do related stories together with the intention of solving one ( or maybe two)  user problems in a given sprint.  If these stories are related then step1 and step2 cant really be parallelized for these related stories.

As a result the team would be doing step1 and 2 for the related stories in the initial phase of the sprint. Then the team would get to coding and then testing.  Producing almost waterfall ? Also, there is going to be very little certainty on the estimates & high chances of missing the sprint goals.

The Approach to mitigate the above problems:  Do the requirement analysis and the high level design before your main sprint starts. Meaning, take up these steps as a part of the previous sprint plan.

Here is how it looks:

 

Sprinting nicely

The orange boxes are the key.

Some part of the analysis( in the orange boxes) can happen as a part of the sprint pre-planning exercise and some can happen as dedicated stories for the team to work on.

Obviously, this wouldn’t be possible for when you have completely new stories coming in the next sprint which were not planned in advance but try to avoid that situation from a Product Planning/Scheduling standpoint. Also, stick to 2 or 3 weekly sprints.  The above approach would be very hard to do in-case 4 weekly or longer sprints.

This is what worked for me, would love to hear your thoughts and experiences in the comments section below.

The only way to make 2 week Sprints Effective

(Context: I am talking about software development teams, who ship using agile methods)

There is only one way: Automation. Automate everything – tests, build, deployment, monitoring, failure notifications. Every kind of test.

I have been in various teams / products where we tried doing this and failed. But lately also part of team where we had accomplished this to a great extent.
Here are the usual symptoms of teams NOT able to accomplish this:
  1. There is a ‘code freeze’ and then there is a dedicated time span – about a week for the QA folks to test the coded new functionality. That means only one week’s worth of code is going to get shipped. Isnt that too little.
  2. Another one is that several bugs get introduced in during these rushed releases.
  3. The QA team is under immense pressure to ship within the given timeline.
  4. The initial part of the sprint is where QAs have lots of free bandwidth.
For a heavenly sprint Automate the builds / deploys and automate tests at various levels.
 
Unit tests, functionality / UATs test automation, automate code coverage measurement, automate look and feel testing, automate security and performance testing and setup rules that if any of these produce major failures – then fail the build and send a notification to the developers / whole team.
 
Comprehensive Automation keeps the quality bar really high. At the same time, the developers & testers have to be on their toes to be able to produce such a level Automation.
 
When this happens here is how a typical sprints looks like:
  1. Dev and QA are involved early on during the design / requirement understanding stage.
  2. The sprint deliverables are broken into small byte sized tasks. Most of which can be coded in less than a day / 2 days.
  3. As and when these tasks are coded, QA starts testing them ( including automating their tests).
  4. Towards the end of the sprint only a few ( say 2 ) tasks are still being coded which typically finish on the second last day.
  5. And there is this last day for testing to finish off stuff and devs to fix any bugs.
  6. Last day EOD – release !
So practically the ‘code freeze’ duration is just one day (or less). Heaven, isnt it  ?

Automation is an engineering team’s brahma-astra to achieve God speed.

May automation be with you ( may God be with you 🙂 ) !

Want to be exceptionally successful ? Combine best practices with an open mind

Experiment
Lots of great leaders / academicians / researchers have written texts, helped define standards, practices, concepts that others can re-use and benefit. 

We also call them best practices. Do you think we should always follow them (by the book) ?
I would say ‘mostly’. That ‘mostly’ is for me to keep an open mind and creating space for some experimentation.
Experiment
Lets take a few examples where not following the erstwhile known best practice or the ‘standard’ was key.

#Think about the advent of Low cost airlines. Not serving free food.
#Think about huge transition happening right now in customer service from traditional call centres to twitter / Facebook.
#Think about the transition from classic waterfall software development model to agile and other new models.

Best practices / industry standards change. Are you with me ?

Practices followed by individuals / teams / companies that take leaps of success or become exceptionally successful are later followed by others.
This is what people start calling best practices and then they later evolve into a ‘standard’.
Think about the classic ‘Product Development Model’ of running a startup to the new ‘Customer development / Lean’ way.
The formula of successful folks, becomes the mantra for others. Did I make my point ?  Read that line again. ( What I meant is that these successful people had to invent their own little formula)
So here is my theory  – “If you want to be exceptionally successful, have the courage to experiment. Be open to trying new ways of doing things”

BUT there is a pre-requisite – for you to not adopt best practices, you must know what exactly you are letting go. That implies you must understand why a particular practice is called ‘best’ – why is that so good. What are those benefits of that practice and in what situation that you are willing to let them go. Obviously, you ll have to know why you are willing to let them go. Have a deep understanding before you play your bets. (Otherwise you would be depending on  your luck too much)
Go experiment wherever you want to ! ( And may be you ll get exceptional results 🙂  )

Dont just solve, solve beautifully !

I have been thinking about it for quite sometime, but this tea-cup in the Indigo flight made me write it. Behold –

20140217-010310.jpg

I told the air hostess to give me a very hot cup of tea.She confidently asked me to touch the pot. I did and gave my approval 🙂 The pot was pretty damn hot.
When she handed over the cup to me, I was shocked. The cup was just comfortably warm. There was a grooved cardboard wrapped around the paper cup.
And it was beautiful. I felt like taking it home to show it to my wife( she is very passionate about art and craft, let me tell you).

Created a wow (although momentary) feeling.

It had the indigo logo on it and a message on the bottom. The design of the cup pulled my attention from a business book i was reading( and I was totally immersed in the book) to this message ” the hottest drink on the coolest airline”.

Brand reinforcement.

I think I ve said enough.
Bottom line – When you solve for a problem( that may be just providing a comfortable cup to hold a hot drink), don’t just solve it, solve it beautifully. Create a wow feeling, make an impression ! Its your baby, Leave your signature on it :).

What say?

How to do a Perfect Sprint Demo

I am talking about Product based companies developing software using scrum methodology. And I am talking about the ‘demo’ and not the sprint review.  The sprint review typically happens at the end of sprint with Product Manager(s) & Designer(s), who review the output of the sprint about what was committed & what got delivered. 

Demo

The Sprint demo is about showcasing your work to a wider audience, senior stakeholders, your consumers, operations, marketing, sales people etc.  I have done dozens of these & experimented with some formats.Here is what worked the best for me:

Format 

  • Total Meeting time: 30 mins
  • Walk through a summary Deck: 5-7 mins
  • Show the demo: 5-8 mins (max 10 mins)
  • Q n A: 15 mins.

Preparation

  • Prepare a 3 slider deck.First slide – a summary of all functional stories delivered in the last sprint, second slide  – non functional, 3rd slide – defects & sprint metrics
  • Prepare a video of the demo. If you want to show a web app for example, show what you want to show on the browser and record it in a video. You can use snagit or quick time for recording a screen cast.
  • Now this video is the most important and trickiest bit.   For this you need to first write a small demo script – which would explain what would happen on the screen and what is the presenter supposed to speak at that time. Meaning what are the audience going to “See” and “hear” in the demo. ( its almost like writing screen play of a movie 😉 )
  • Write the screen play :
    • You need to weave all the stories delivered in the last sprint in an easy to follow video movie.
    • Make sure you give enough pause at each step where you can talk about what the audience are going to see next.
    • So things like clicking on a link, expanding a particular section, scrolling down a page – need an explanation as to why you are going to do that and what should the audience expect to see. So keep that in your screen play.
    • Repeating a point sometimes does not hurt.
    • Write a flowy script & tell a story about what real user problems are being solved.
  • Rehearse the script by following the steps on your software. When you feel ready, record the demo video.
  • Ideally you should record your voice along with the video too. ( this would be useful when you share your video with folks offline)
    • While recording your voice – use an excited & happy tone.
    • Give pauses at the transitions, tell them what they are going to see, after they have seen it, repeat what they saw.
    • Go in a flow, but at the same time, be a bit slow so that audience get time to soak it all in.
  • When the video is done, rehearse a bit again – be ready to give your confident voice during the actual demo.

At the Demo 

  • You are at stage.  Be confident. Welcome people with a smile 🙂
  • Set an expectation that questions ideally should be raised at the end.
  • Start with the deck and then quickly get to the video. ( you need to finish both in 15 mins)
  • Ideally, having the deck open in a small window on the side while the video is running helps.The audience can always see on the side to know what all is being covered in the video. ( or you can weave the deck into the video itself  – for a making it even better  )
  • Play the video and give your voice during the demo. ( Although the voice is preRecorded too, but keep that on mute, live sound energy is way better for a live audience 🙂 )
  • Make sure you sound energized and excited !
  • During the QnA round – if there is time left, feel free to call out individual attendees for their questions, comments, cover folks on the phone line too.  ( the names you noted initially would now help).

The above worked wonders for me, what about you ? Please do share your experiences below.

Paytm – you are awesome !

Dear Paytm,
I have been using your service for a year now I think (and have roughly made 50 odd recharges through your site / app).
Not just that, I think I have recommended your services to many many of my friends. The best thing I like about you is that it takes about 20 seconds for me to do a recharge. THAT was great !

BUT then sometime back you had some outages (you were probably doing some back-end upgrades) and I had some trouble recharging.
But I wasn’t worried ( everybody goes through a rough phase I thought)  and  kept coming back & kept trying to recharge. I was somehow sure that my money was safe with you.

AND THEN, I saw the “We r sorry” email you sent me (at the bottom). I just loved it. I loved your care, professionalism and humility ! 
I forwarded this mail to a few  friends of mine (they liked it too. I showed it to a colleague of mine & told him the outage story.  He too was impressed.

I had not written a  post in a while but you forced me to 🙂  You WOWed me & taught me a lesson on treating your customers well!

Thank you !
The email I got from you:

Hi there,

We introduced a change on our website last week (Refresh) and that didn’t go as smoothly as we had planned.

For the first three days, about half of our visitors had difficulty in recharging and about 5% of you experienced Cash refund related problems. Our software upgrade caused a large amount of unanticipated problems despite all of our planning.

Those problems are behind us now and throughout the past week our Care team has reached out to those of you who were affected and addressed your issues. We have solved these software issues and have been seamlessly handling all requests.

Throughout this glitch we have guaranteed that your money has remained safe – your trust in us is the most important thing to us. This was our primary goal.

If you are still facing any issues, do write in to care@paytm.com with the subject line“Fast track”

On behalf of our entire team, I again extend a heartfelt sorry for the trouble we’ve caused you and invite you to give us a chance again. I am amazed to see how many of you love to use Fast Forward so in case you haven’t used it yet, please give it a try.

At your service,
Harinder
On behalf of Team Paytm