Passions, People & Products

Passion is the genesis of genius

– Tony Robbins

 

Passion

 

Show me a great product (or service) and I will show you the passionate people behind that endeavour!

So what exactly is passion? Quite simply, passion is that invisible energy that drives people to go beyond what an average Joe can do. Among its many dimensions, here are the 5 most important:

  • Ownership: Passionate people don’t wait to be given formal ownership and responsibility – they assume responsibility and work towards doing the right thing. If something that needs to get done is not getting done, they are the first ones to roll up the sleeves and get it done – no matter how unpopular or unpleasant that task is! Passionate people are informally seen as the “go to” people in an organization even if they don’t have a suitable title.

 

  • Motivation & Drive: Passionate people don’t need to be told what they need to do and how they need to do it. They are self-driven and they drive themselves (and others) to do whatever it takes to get the job done. These are usually the people that don’t suffer from monday morning blues!

 

  • Second level thinking: First level thinking is the simplistic and superficial thinking/analysis where you are looking at the obvious – one is barely scratching the surface. Second/higher level thinking is when you are start peeling the onion layers – you evaluate the range of possible outcomes, probabilities and start considering countermeasures as needed. Passionate people think and see beyond the obvious – always 2 steps beyond/deeper what most people can think or see. Attention to detail is one of the manifestations of higher level thinking – more on that topic here

    You can read more about second level thinking here, here and here.

 

  • Persistence & Grit: In corporate there are plenty of obstacles – budgets, timelines, conflicting priorities, group fiefdoms & politics, incompetencies etc. Most people get caught up in the obstacle waterloo and cannot go beyond. Passionate people are usually able to power through these hurdles and accomplish what they set out for – all they see is the goal and not the obstacles in their way. In the early days of Tesla, Elon Musk had to fund Tesla with his personal finances and he was close to being bankrupt – he just kept going!

 

  • Pride: Passionate people see their work as a reflection of themselves and their capabilities and they will go to extreme lengths to make sure that what they put out is something that they can be proud of. 

    I have a designer JS on my team who was about to have his second child around the same time we were making some crucial choices on our product’s redesign – color palette and other visual design directions. Rather than leave these crucial decisions to his temporary replacement, JS took his laptop to the hospital and was cranking out designs from the delivery room (probably to his wife’s chagrin)! Our product was also his baby and he just couldn’t let somebody else dictate his baby’s visual design – that’s pride!!

 

Want to see what passion looks like? See Elon Musk (founder of Tesla & SpaceX) in this 2 min video – he actually cries listening to the critique from the very people he admires & worships!

Being passionate is one step short of being crazy – and people like Elon Musk, Jeff Bezos, Travis Kalanick & Steve Jobs personify that!

 

Advertisements

Building Products & Saying NO

 

Learn to say NO to the good and the advantageous, in order to receive the best!

― Sunday Adelaja

SayNo

If your Product Management team is responsible for building products, features/ideas get thrown at you – by your product team members, sales/marketing/support groups, competitive analysts, customers, partners, executives, etc. On one hand, you have the responsibility to ship a well-rounded and a well-balanced product that serves the needs of your customers. On the other hand, you have the wish list fire-hose pointed at you.

Arguably the toughest decision a Product Management team makes is – what features to include and what features to exclude. What do you build now and what do you postpone? If the goal is to offer a well-rounded product experience to your customers, I would argue that what you say NO to is more important than what you say YES to.

Rather than making ad-hoc YES/NO or NOW/LATER decisions, here is an objective framework that mitigates the subjectivity in this decision-making process using 5 vectors of evaluation:

 

1. Utility Value & Breadth of Impact: This one is fairly straightforward. For the feature in question, ask yourself (from a customer perspective) 2 questions – (1) how useful is this feature (2) what % of my user-base will find this genuinely useful. Where possible use data to support your decisions – e.g. you could analyze your Google Analytics stats to understand how often a similar feature is being used in your existing product. These questions will help you weed out “pet projects” or cool sounding features that have little or no utility in real world.

 

2. Table Stakes: In late 90’s, much before Bluetooth and USB became popular, some computers offered IR (infrared) ports so that devices like PDAs could wirelessly connect to computers. In reality, these IR ports were rarely ever used. However, because an IR port was a common requirement in the corporate purchase checklist, most laptop manufacturers would include the IR port in their corporate class laptops even though they were rarely ever used – i.e. the IR port became table-stakes in the corporate laptop market.

Another contemporary example is the phablet product.When Samsung launched their Note phablet in 2011, it became a runaway success. Apple on the other hand, stayed away from phablets given Steve Jobs’ disdain for the large devices. Samsung Note was capturing so much market share (especially in Asia), after 3 years of resisting, Apple capitulated and launched their iPhone 6 Plus phablet in 2014 – they needed a phablet in the product lineup to stay competitive.

In your market, is the feature under consideration table-stakes based on customer requirements or competitive positioning? If so, you may no choice but to offer that feature sooner or later.

 

3. Basic VS Advanced: A few months ago I upgraded my audio receiver to a Sony DN1050 – I needed a receiver with AirPlay support. The DN1050 is a pretty sophisticated receiver that supports AirPlay, NFC, multiple zones, 4K scaling, Bluetooth, Wifi, DLNA, Pandora, Spotify, etc. BUT… it only supports 2.4Ghz wifi – no cigar with 5Ghz wifi support. Arrrgh. Why would a world class company like Sony build a sophisticated $600 consumer electronics product that relies on wifi and yet exclude 5Ghz support. My $50 Echo Dot supports 5Ghz!

This is a classic example of a somewhat disjointed product that supports sophisticated features and yet misses the basics (5Ghz wifi channel support) – that’s a head scratcher.

When building products, it’s important to cover the basics before you start considering advanced/complex features. This is a fairly simple principle and yet it eludes so many products!

 

4. ROI (effort vs benefit): Every so often you come across a feature that sounds useful – but expensive to build (in terms of time & resources). If that feature is applicable broadly, benefits a wide swath of your user-base, or gives your product a strategic edge, it may warrant making that investment. Otherwise punt it for later!

 

5. Strategic Importance: When Apple launched Siri in 2011, it was labeled as a beta. As far as I know that was the first time Apple released a feature labeled as beta (while embedded within a mainstream product) to general public. Apple knew that Siri was not fully ready for prime-time and yet they released it early on because of its strategic importance. By releasing it early and collecting anonymized voice samples, Apple was able to iterate and improve Siri over time. Now Siri is an integral part of their iOS, macOS, watchOS and tvOS.

 

Summary: For every feature/capability on the product roadmap, it’s important for Product Management teams to consciously deliberate on the YES/NO decision based on objective criteria that suit your needs (market requirements, competitive situation, strategic importance, product maturity stage, etc.). Without this deliberation, if every idea gets a YES rubber-stamp, products runs the risk of becoming a disjointed mishmash that could earn your customers wrath!

Power Users maketh Good Product Managers

Power User

Every so often I meet an intern, an engineer, a marketing guy or somebody that asks “How do I become a PM (product manager)? What makes a good PM that builds great products?”

Usually my return question is “For which products do you consider yourself a power user?” I get this quizzical look – what’s being a power user got anything to do with being a product manager?

Turns out, a lot!

If you are in the tech industry, depending on your role, you use products like Outlook, Word, Excel, PowerPoint, Jira, Adobe Illustrator, iOS/Android/Windows/Mac etc. for a few hours everyday. If you spend a few hours everyday on these products, did you take the time to get a deeper understanding of how these products work & use them better? Some examples:

 

Microsoft Windows:

With a 90% market share, chances are that you have used Microsoft Windows for dog years.

  • Ever use the Windows registry to customize the OS or any application to suit your needs when such a customization is not available via the usual “Options” route? See some examples here…
  • Ever used Windows “Event Viewer” to diagnose any problems?
  • Ever customized Windows “Power Options” to suit your own needs?

 

Outlook:

  • If you send regular emails to a set of people, did you ever create a “Contact Group” – a personal distribution list (not the corporate distribution list) of those people and use that for your emails?
  • Ever install and configure an Outlook plugin other than what’s already installed by default on your computer?
  • Ever setup your work email and personal email in the same Outlook instance so you can conveniently switch between work and personal email?

 

 

WhatsApp:

  • Did you ever go into “Settings > Data & Storage Usage > Storage Usage” and see which groups are consuming too much storage? Deleted videos that take too much storage?
  • Ever posted messages with bold/italics formatting? Here is how you do it…
  • Ever used WhatsApp on a desktop browser rather than using it on a phone? Here is how you do it…

 

PowerPoint:

  • Did you ever customize the master slide design & layout to suit your needs and save it as your own theme to use it on an ongoing basis? Do you understand how customizing the slide master affects other layouts in your deck?
  • How good are you at using the advanced animation effects in PowerPoint – e.g. the motion paths animation?
  • Do you customize the deck for 16:9 or 16:10 aspect ratio of your monitor/projector?

 

Hopefully you get the drift of where I am going!

If you are a power user of any product, you will observe & learn 2 things:

  1. Product design patterns
  2. Attention to detail

Product Design Patterns: Successful products usually offer a breadth and depth of capabilities that are well layered. Take Microsoft Office for instance. A novice can easily get started on Office products. As the user’s needs grow, Office can keep up with its breadth and depth of features without being too overwhelming. As a power user, if you can leverage a product’s breadth and depth of capabilities to your advantage, you have a better shot at being a good PM that builds sophisticated products by applying similar design patterns to your products.

Attention to Detail: Great products offer a refined user experience driven by attention to detail. If you appreciate the attention to detail in great products, there is a good chance that you will build products that have similar attention to detail. More on that topic here…

 

Incidentally, I find it a great interview question when screening PMs – “Which products do you consider yourself a power user for?”. If the candidate is a power user of a few products, this person has a good shot at building better products!

Partnerships, Product Launches & Pain Management

 

We must all suffer one of two things – the pain of discipline or the pain of regret & disappointment!

– Jim Rohn

 

partnership

 

Technology companies launch products/services using their own technology/IP. Occasionally, such products/services are launched based on a partnership between 2 (or more) companies. The nature of the partnership can vary – a partner relationship where both company names are visible (e.g. Powered By) or a white label relationship where only one company’s name is visible.

Partnerships are explored and established typically at C level with involvement from business development, finance, legal, product & engineering. Agreements are inked to settle details such as revenue share, IP ownership, product development, legal liability, customer support, marketing, etc. More often than not, deals are painted in broad strokes (and a generous measure of good faith) while the finer points are left for the product teams to figure out along the way.

Launching well rounded products is hard enough. Launching a product hinged on collaboration across two different companies and teams, the complexity & pain increases threefold because of the challenges involved around less transparency, less control, varied priorities, cultural differences, etc. This blog post attempts to put a framework around what it takes to develop & launch partnership based products/services while minimizing the pain along the way – a useful structure for product teams to ship a well-rounded product.

 

  • Functionality Brief: This is arguably the most important first step. After the deal is signed, Product Heads on both ends should work together a produce a “Functionality Brief”- a 1-2 page document (or a couple of slides) that broadly lists ALL features/functionalities that the partnership intends to deliver. It’s a simple document with one bullet per product functionality. The intent of this brief document is to broadly establish the complete scope of the deliverable – not a long MRD/PRD. The brevity of this document allows the team to see the “forest” without getting lost in the “weeds” of BRDs/MRDs/requirements.

 

  • Meeting of the Minds: While some amount of technology due diligence may have happened during the initial stages of partnership discussions, those discussions usually tend to be guarded. Now that the deal has been established, it’s time to open up the kimono and get down to brass tacks. It’s time to get the architects, subject matter experts and a couple of key engineers from both sides into a room to start whiteboard discussions on what it takes weave technologies from both ends.This sort of meeting MUST to be face to face – conference calls over Webex isn’t going to cut it. In my experience, this event works best when it happens over 2-3 contiguous days. The first day is usually spent with team members knowing each other and getting familiar with technologies on both ends. After the ice-breaker dinner & drinks together on the first night, rapport gets established & the discussions and white-boarding sessions are a lot more lucid and productive on days 2 & 3. By the end of day 2/3, product teams on both ends usually have a pretty good sense of the technology alignment and pitfalls if any.

 

  • Proof of Concept: Depending on the nature of the project & complexity, before beginning full scale product development/integration, it might be useful to do a proof of concept project. Any toxic asbestos or technology incompatibility is best discovered sooner than later.

 

  • Cross Functional Team, Roles & Responsibilities: Once a broad alignment of products/technologies has been established, it’s time to bring in the usual suspects to get the project going  – product management, engineering, QA, project management, analysts, etc. and assign clear roles & responsibilities. While BRDs, MRDs, PRDs, requirements, design documents, specs, etc. are useful to manage the execution within each function, the Functionality Brief that was developed as a first step keeps the team on the same page with regards to overall deliverable.

 

  • Customer Support: This item usually gets under estimated & ignored until much later. If company A has to provide support for pieces of product/technology from company B, it takes a non-trivial amount time and energy to get the customer support people trained. If the company A is a large global company with footprint in AMER/APAC/EMEA, the complexity gets further compounded. It’s best to involve the customer support team early on so that they can plan for training, documentation, escalation paths, etc.

 

  • DL for Communication: Create an email DL (distribution list) with members on both sides of the fence – makes it easy for everybody to communicate important details across both teams. While this may seem like a trivial tactical detail, without a DL, you can be sure that some members of the team will be dropped inadvertently on important communication and that creates a different dimension of pain (confusion, transparency, trust, etc.)!

 

  • Strong Program Manager: Given that there are 2 companies and 2 teams involved, its best to have a “stronger & savvier than usual” Program/Project manager who can deftly herd the cats while managing the scope, schedule, risks and resources.

 

  • Executive Sponsors: As product development/integration progresses, issues occasionally come up that require escalation & decision making at higher levels. Identifying executive sponsors on both ends upfront makes it easy to resolve the issues as they come up. Pick a sponsor that has the title/authority to make decisions, bandwidth to handle issues as they crop up and a temperament to work cooperatively with an external partner to resolve conflicts.

 

Delivering well rounded products based on partnerships can be painful but the above framework makes for a useful pain management!

 

Balancing Trains and Product Roadmaps

 

Balance to life is kale shakes and cupcakes!

– Joe

 

Product Train

 

Founded in 1853, the state owned Indian Railways has one of the largest railway networks in the world. With over 71,000 miles of track spanning 7000+ stations carrying over 8.3 billion passengers annually, it employs over 1.3 million people. Indian Railways generates about 70% of the revenue from freight traffic while the remaining 30% comes from passenger traffic.

Given the socialistic background of the Indian government, freight business profits are used to subsidize the passenger ticket prices so that a common man can travel very inexpensively. You could travel by train from Mumbai to New Delhi (about 900 miles) for a super low price of around $10! To enable such a low price travel, Indian Railways has to balance many variables such as freight-versus-passenger traffic, frequency, route planning, staffing levels, passenger convenience, amenities, capital expenditure, service quality, safety, etc.

In many ways, balancing train operations is very similar to balancing product roadmaps. And yet, if you look around, you will find plenty of examples of technology products (especially from big companies) that are a bit of a train wreck – uninspiring, buggy, unintuitive, slow, clunky to use, etc.

 

Why is that?

Unbalanced Product Roadmaps!

 

As companies get bigger, there is a pressure on product teams to prioritize items that have a direct ROI. While that intent is noble, it typically results in a situation where new features/functionalities are given much higher importance. Every subsequent release gets stuffed with more and more bells & whistles to appease external customers & internal stakeholders (sales, marketing, execs, etc.) and also because it’s easier to justify ROI with new features.

With this intense focus on new features & functionality, 2 things usually get the step-child treatment:

 

  1. Infrastructure Improvements: Every technology product has frontend/backend infrastructure like databases, middleware, messaging, caches, security framework, identity management, UX frameworks, analytics, test automation, etc. Keeping this infrastructure humming takes a non-trivial effort on an ongoing basis. And yet, such infrastructure improvements typically take a back seat because improving/maintaining it is not as sexy as product bells & whistles.
  2. Refinements: This is polishing the product to a shine – bug fixes, performance improvements, UI/functionality tweaks, usability improvements, etc. It’s the little details that elevate the product experience. Again, this area typically doesn’t get much love.

 

Over a period of time, as the products get stuffed with more and more bells and whistles with little attention to Infrastructure Improvements and Refinements, the product becomes clunky. Technology industry even invented a term “technical debt” to describe this. It’s a fancy way of saying “we didn’t do stuff that we should have and we kicked the can down the road”.

 

What’s the mantra to prevent that?

Balanced Roadmaps!

 

When planning product roadmaps, management should mandate product teams to present a balanced roadmap. Every product release should offer a balance of Features and Functionalities, Infrastructure Improvements & Refinements:

 

Balanced Product Roadmap

 

Typically, I guide my teams to allocate about 60% of the bandwidth to Features and Functionalities, 20% to Infrastructure Improvements & the remaining 20% to Refinements. While this allocation can vary, in the long term, this structure allows product teams to deliver solid well-rounded products in a disciplined manner without incurring “technical debt”!

Methodically Ignoring Your Customers, Again?

Customers are like teeth. Ignore them and they’ll go away!

– Jerry Flanagan

 

Ignored Customer

 

You read that right! Many medium/large sized companies in Corporate America have processes that methodically (but unintentionally) ignore the customer – especially in the software technology space. Here is what I mean…

Consider a medium/large sized company Acme Corporation that is in the technology business (my domain). When the product teams (comprised of Product Managers, Eng, QA, UX, Marketing, etc.) plan the next big version of the product, they seek input from key stakeholders. Sales teams provide feedback on new features/functionality that lets them close more deals. Customer Support provides input to improve product quality & reduce support contact thereby bringing cost savings. Marketing provides competitive information and other inputs to better position the product against competition. Different stakeholders provide inputs that impact their groups. So what’s missing?

What about your existing loyal customers who religiously use your product/service’s existing functionality? These loyal customers are your bread and butter. Chances are, they are being methodically ignored during every product cycle – here’s how:

When existing customers or prospects request new features that are deemed “major”, such requests are usually acted upon. If customers complain about egregious problems, they get fixed. What about problems that are “minor” inefficiencies, irritations or improvements? Often customers don’t proactively complain about what they see as “little issues”. Even if they complain, often that feedback gets lost in the process because those issues are prioritized as “minor” and get ignored. Over a period of quarters and years, these “minor” product issues accumulate and the end result is a product that’s heading towards mediocrity.

Why does this happen?

Engineers want to work on cool new stuff. Product teams are pressured into working on items that affect the sales top line or cost savings bottom line. Items that make the teams look good in QBRs (quarterly business reviews) get a higher priority. Egregious problems do get fixed, while the “minor” issues/irritations/improvements often get ignored. As a result, without the product teams realizing, the product gradually creeps towards mediocrity.

Don’t believe what I am saying? Take a look at your company’s HR, Procurement, Contract, Inventory, Quoting, Payroll, Legal or such similar software. Barring an exception or two, chances as, these products have mediocre user experiences (clunky, un-intuitive, hard to use, missing functionality, etc.).

How to avoid this march to mediocrity?

There’s at least 3 ways to monitor & address this.

  1. Measure Customer Satisfaction: Senior Management needs to actively drive the exercise of bi-annual (or annual) customer satisfaction measurement. NPS (Net Promoter Score) is an industry standard methodology of measuring how likely your customers are to refer your product/service to others. NPS is a direct reflection of customer satisfaction. Management needs to measure NPS (or an equivalent metric) on an ongoing basis and make this score a part of the KPI (key performance indicator). This gives an incentive to product teams to pro-actively address the minor issues.
  2. User Research: Most companies under invest in user research – read more on this here. When user research investments & activities are increased, product/service niggles are uncovered that can be then proactively addressed by the product teams.
  3. Dedicate Bandwidth: Product teams should dedicate a non-trivial percentage of engineering bandwidth (e.g. 10% – 20%) and use this bandwidth to exclusively focus on improving existing product functionality (not new functionality). This forces product teams to proactively address  “minor” issues & details that often get swept under the rug. Click here to read more on the topic of little details.

 

None of this is rocket science. It’s a matter of Management and Product Teams deliberately setting priorities and allocating investments & resources to make sure that customers and products experiences are not getting ignored!

 

Driving Big Impact with Little Details

Little things make big things happen!

– John Wooden

Attention to Detail

Ever wondered what sets apart a 3-star Hilton from a 4-star Hyatt? A 4-star Hyatt from a 5-star Ritz Carlton? End of the day, they are all hotels with similar amenities – beds, bathroom, linen, TV, writing desk, swimming pool, front desk etc. So what gives?

Attention to Little Details!

Among other things, the biggest differences within different levels of hotels are the little details that translate to a more refined customer experience. As you go up the star chain, the attention to detail gets better – the guy behind the desk is better dressed and more helpful, the bed sheet thread count goes up, pillow menu – multiple pillows of varying softness, the room décor & accoutrements are more refined, swimming pool is better maintained, nicer landscaping, parking lots are better paved & lighted, etc.

However, when it comes to the technology world, for a variety of reasons, there is a lot of focus on ROI driven “big bang” features and functionality while refinements and attention to smaller details often take a back seat.

When using products (and driving my teams that build technology products), I tend to pay a lot of attention to little details. Here are a few that I love:

  • Palm Treo (RIP): The Palm platform had its own share of rabid followers until iOS/Android ate its lunch (and dinner). On the Palm Treo when you received a call, there was a little button on the lock screen that let you send a text message “Call you back in 10 mins” with one click of the button. That’s a clever little detail that I always wanted on the iPhone – Apple added this last year in iOS 8.
  • Microsoft Outlook’s Insert Screenshot: A lot of people in corporate world would rather give up their first born than give up Microsoft Outlook on Windows (I am probably in that camp). When writing emails, you often need to add a screenshot to illustrate your point. Outlook’s email compose window has the “Insert > Screenshot” menu to quickly add a screenshot. This is one of those little gems that saves the tedium of “capture screenshot > save image to desktop > attach image to email > delete image file on desktop”.
  • Apple Magic Mouse 2 “Sound”: One can’t talk about attention to detail without an obligatory mention of Apple! Recently Apple released the Magic Mouse 2. With all the changes they made, apparently the mouse didn’t “sound right” when it was moved around on the desk. The engineers had to continuously tweak the bottom polycarbonate runner geometry until the mouse “sounded right”. Read more here…
  • BMW 328i: Cars have 5 to 6 buttons on the dashboard to program your favorite radio station. BMW takes those 6 buttons to the next level with 2 refinements: (1) Those 6 buttons are touch-sensitive – if you lightly touch (not press) any of those buttons, the dashboard display shows the radio station (or action) assigned to that button. (2) You can assign different actions to those 6 buttons – not just radio stations. I programmed the 6th button in my wife’s car to the navigation system’s “Go Home” functionality. When driving in unfamiliar neighborhoods, to head home, all my wife has to do is press the button 6 and the navigation system fires up to head home. This really saves her the distraction of futzing around the multi-level menus when driving. Clever!
  • Google Express: Yesterday I ordered a few items on Google Shopping Express. When they were delivered in the evening around 7:45pm, there was a problem with one item in the batch – the lid for a liquid soap bottle was broken. At 8pm somebody from Google Express called to discuss the issue. Usually delivery services expect the customer to contact the company when there is a problem. In this case, Google Express proactively called me to discuss the issue. To make that happen, Google had to setup a process where the delivery driver notifies the back office about a problem & the backoffice calls the customer immediately (at 8pm) – providing that level of service requires a non-trivial investment of time and resources. Kudos to Google!

So, organizationally (not at an individual level), how to drive attention to detail?

3 things come to my mind:

  1. Resources: You have the ask the tough question – do my teams have the people and resources to deliver attention to detail? Quite often, teams are spread thin – too few people doing too many things – structurally that does not lend itself attention to detail. In order to deliver attention to detail, you need to make sure that people aren’t spread too thin.
  2. Hiring Right: Hire the people with the right background, culture and mindset. Hiring a chef from Taco Bell for a job at Ritz Carlton doesn’t work!
  3. Set the Bar: An expectation & bar needs to be set with regards to attention to detail – AND hold people accountable to that bar. For example – if your product/service doesn’t meet the expected bar, delay the launch. That puts the pressure on the teams to keep working until the bar is met.

Summary

Whether its products or services, B2B or B2C, in addition to ROI driven activities, features and capabilities, teams need to invest time & resources to pay close attention to detail. That is how products/services build a strong fan base that resist abandoning your product/service when a competitive product/service with a cheaper price comes along.

No wonder successful companies like Apple, Lexus, Ritz Carlton, Microsoft, etc. consider “attention to detail” a big part of their strategy to deliver great products/services!