Price-Value Equation with App Store & Google Play

Price is what you pay, value is what you get!

– Warren Buffett

With over 3.5 billion smartphone users and 1.26 billion tablet users worldwide, in Q3-2020, consumers spent $29.3 billion in mobile apps across Apple’s App Store ($19 billion) and Google Play ($10.3 billion). Apple and Google take their fees before disbursing the rest to App Developers. Both Apple and Google have the exact same fee structure – 30% for one time purchases. For subscriptions, the fee is 30% for the first year and 15% for subsequent years.

This fee structure has become a bone of contention in the recent months as Epic Games dukes it out with both Apple and Google. Are these fees outrageous and unfair? Are Apple and Google monopolies that bully App Developers to extract their pound of flesh? Should their fees be lower, should it be zero?

Business arrangements are simply a matter of “price and value” (i.e. the gives and gets) – you give a price and get value in return. The price App Developers give to Apple & Google in the form of fees is quite clear. What value do they get in return for that fee? Let’s look at that:

  1. Developer Platform: Both Apple & Google have hundreds of people on their payroll (engineers, QA, product managers, designers, program managers, developer support, evangelists, etc.) building world-class iOS & Android developer platforms (XCode/AndroidStudio, APIs, SDKs, Play/AppStore, infrastructure for app beta testing, submission, management, distribution, monetization, etc.). These development platforms make it easy for App Developers to build, market and monetize their products.
  2. App Discovery, Visibility and Customer Acquisition Cost: In a centralized App Store & Google Play, consumers often organically find and discover apps. If an app is in the Top 50-100 of any category, the visibility and the organic downloads that the app gains from hundreds of millions of eyeballs is priceless – App Developers cannot buy that sort of a visibility. For App Developers, to the extent they get organic downloads for zero acquisition cost, that’s a huge value – it lowers the overall cost of customer acquisition.
  3. Payment Processing: Building products is actually fun. Processing payments, refunds, risk management, fraud handling, compliance, regulations, etc. – not much fun. For most businesses, payment processing is a necessary pain-in-the-butt. To start with, businesses pay 2.5% – 3.5% transaction fees to process credit cards. In addition, businesses incur substantial development and ongoing maintenance costs associated with payment processing, refunds, risk management, fraud handling, compliance, regulations, etc. In the apps business, App Store & Google Play take care of those nasty issues and App Developers get one direct deposit into their bank account at the end of every month – simple. This allows App Developers stay focused on their core job – building and marketing products.
  4. Piracy Protection: Revenue losses due to software piracy is real ($46.3 billion in 2018). For every dollar a Software ISV rakes in, they lose cents/dimes to piracy. With App Store & Google Play, there are mechanisms in place to prevent piracy. As a result, consumers get vetted malware-free apps while App Developers don’t lose money to piracy.
  5. Enabling Free/Freemium: App Developers launch free/freemium apps (e.g. Facebook, Tiktok, OpenTable) that either don’t monetize or monetize via external mechanisms (e.g. advertisements). Both App Store & Google Play support this model with their distribution infrastructure and that costs real money.
  6. Tax Compliance: When you sell anything (not just apps), depending on where you are and where you sell, the revenues are subject to all sorts of local/state/country taxes – a hot mess that makes the head spin (see this and this). There are companies (e.g. Avalara, Digital River) whose bread-and-butter is handling this sort of tax compliance and their fees are not cheap. When App Developers sell their apps on App Store and Google Play, Apple and Google take care of all tax collection, remittance and compliance issues. Yes, this is an arcane issue but it’s real. True story – I used to work for a large multinational company that had a billion dollar revenue base. When it came to tax compliance, we decided to sell our mobile products only in those countries where Apple and Google took care of tax compliance and turn off the other countries where the tax handling onus was on us. Despite having our own finance department, our analysis showed that it wasn’t viable for us to handle the tax compliance!

So, what’s the cumulative worth of all these values? How does value compare to the price – i.e. fees paid to Apple and Google? As they say, “beauty is in the eye of the beholder” and this is my experience…

Apple launched iPhone SDK on 6-March-2008 with a customary keynote event. After I saw the keynote that day, I was so inspired and energized with the App Store platform, I literally ran to Valley Fair Apple Store that same night and bought my first MacBook Air. That very night, as I was messing around with Xcode and iPhone SDK, I launched my app startup SpiceLoop. Between March-2008 and April-2012, I launched 4 apps across App Store & Google Play and drove a few million downloads. During those 4 years, I paid hundreds of thousands of dollars to Apple & Google – their 30% fees. Would I have been happier with a lower fee structure? Hell, yeah! Did I resent Apple & Google for the fees I paid? Hell, NO. I was convinced that the value I was getting out of the App Store ecosystem was beyond fantastic. Apple (& Google later) made it so easy for me to build, launch, market & monetize my apps, I had no hesitation in launching an app startup the night the iPhone SDK was launched and I had no qualms sharing the 30% fees. As an entrepreneur building apps for iOS & Android, I felt that my price and value equation was fair and equitable!

For 4 years I walked many a mile in App Developer shoes. Should Apple/Google drop their fees to zero – hell, NO. Both Apple and Google took huge risks and spent massive amounts of money to build and nurture their platforms over the years. What they built provides livelihood and tremendous value to App Developers and for that they deserve to be compensated. Apple and Google have every right to enforce their monetization policies and protect their revenues.

It’s important to have some historical perspective. Prior to 2008, to do anything in the mobile space, Developers had to bend over backwards and pledge their firstborn to the likes of Nokia, Blackberry and telecom carriers. In March-2008 Apple came along and opened up the playing field to all Developers. When Apple set their 30% fee structure in March-2008, it was nowhere as powerful/successful as it is today. Later Google Play followed suit with the same fee structure and App Developers happily flocked to App Store and Google Play. That 30% fee has stayed same since day one. Today when Apple & Google are accused of highway robbery, monopolistic practices and putting a stranglehold on innovation, I scratch my shiny dome in wonder (and exasperation)!

Should the fees be lower than 30%? Like I said, beauty is in the eye of the beholder! App Developers need to examine their price and value equation and make their own judgement!

Apple Card – A Curious Case of Flywheels, Ecosystems, Moats & First Principle Thinking

 

Credit cards are like sins, enjoy now & pay later!

– Anonymous

 

Apple Card Fly Wheel

 

Flatbush National Bank of Brooklyn was the first bank to issue a credit card in 1946. By the end of 2017, just within US, there were 364 million open credit card accounts with Chase, Capital One and Bank of America as the 3 biggest credit card issuers. An average American today has 2.9 to 3.7 cards. Saying that this space is “hyper-crowded” would be an understatement.

In this mature hyper-crowded landscape, Apple launched their Apple Card earlier this week. In this blog post, I’ll try to analyze the elements underlying the Apple Card product strategy while delegating the other aspects (financial features, benefits, comparison with other cards, etc.) to the trade rags.

Let’s start with the onboarding experience which I believe is a core part of the Apple Card product strategy.

 

Onboarding Funnel & Friction: Every product team tries (to a varying degree) to manage their onboarding & adoption experience, but very few v1.0 products deliver a perfectly polished onboarding experience. Apple Card v1.0 managed to deliver that, any traces of onboarding friction has been nuked with a vengeance.

Earlier this week I got an invite email to apply for the Apple Card. Clicking the invite (in iOS Mail) took me into the iPhone Wallet app to start the credit card application process. Since Apple already knew my name, phone, email, address, etc. everything in the form was prefilled. The only 2 pieces of information I had to enter was my annual income and last 4 digits of social – that’s it. The Wallet app did beep-boop for 3 seconds and confirmed that Goldman Sachs approved my application for $20k. This entire journey of “credit card application → Goldman Sachs approval → accept card -> card added to Wallet → make it default for all Apple payments → enable for Apple Pay →  ship a physical card? → card ready for use” took less than 90 seconds – yes, less than 90 seconds. Apple made it sure that if you had an iota of curiosity/intent to get the Apple Card and clicked a button or two, you will end up with the Card – it was that frictionless!

In contrast, Wells Fargo bank that has known me for 20+ years, wants to know my mother’s maiden name, housing status, monthly mortgage payment, employment status, occupation, current employment length and half a dozen other data points before it takes me to the next step… fuhgeddaboudit!

 

Card Experience: A lot has been written and ooh-aaah’ed about the Apple Card user experience, benefits, comparison with other cards, etc. (see this, this and this). I won’t repeat the details, but I’ll mention top 10 highlights for the sake of context and completeness. Like all things Apple, the Apple Card experience in the Wallet app is well polished where you can see: [1] how much you spent, where, in what categories [2] card color is a heat map that reflects your spending pattern [3] merchant details, location, etc. [4] weekly/month spending trends [5] cash back amount that you accrued [6] setup end of the month payments [7] your credit limit, available credit, APR [8] push notifications when your physical card is about to be delivered [9] 1-click activation of the physical card [10] reach Apple Card support via text messages (that’s really cool).

The end to end Apple Card experience is tailor made for the impatient gen Z iOS kids who grew up suckling on the iPhone teat. As they come of age ready for credit cards, at least in US, I’m betting that they will gravitate towards Apple Card’s mobile-first experience rather than a Chase or Wells Fargo card.

 

Ecosystems, Moats & Switching Costs: When you are a large company with many products, you try to gain “unfair advantages” by doing proprietary integrations into your own ecosystem. Microsoft products tend to be integrated into Windows & Office franchise. Google products are integrated into their own portfolio – gmail, maps, Android, calendar, hangouts, etc. Predictably so, Apple weaved the Apple Card experience with their Wallet, Apple Pay, etc. In addition, they did a couple of things very subtly that I thought were really interesting.

  • Apple Card comes with 2% cashback when you use it via Apple Pay. However, this cashback declines to 1% if you use the physical card. Apple really wants you to use Apple Pay and not that plastic card. In 5 years since its launch, Apple Pay is accepted at 65% of all retail locations and 74 of the top 100 merchants in US. With the combination of Apple Card + Apple Pay, they want to continue moving the needle from 65% towards 100%. Besides, using the Apple Pay via iPhone is supposedly more secure than using the plastic card – an aspect I’m not familiar with.
  • In all these years, Apple had my credit card details to charge my AppStore purchases. Now, to pay the Apple Card balance at the end of the month, I had to give them my bank checking account details – something they never had access to. I am willing to bet that Apple will use my bank account details in a meaningful manner down the road.
  • The 1%/2% daily cashback from your Apple Card spending goes into your Apple Cash debit card (issued by Discover) and NOT into your Apple Credit Card. In all these years, like most users, I never bothered using Apple Cash Card. With this move, Apple is herding its users to use Apple Cash Card in additional to the Apple Credit Card. Now that I have $8 in my Apple Cash debit card, Apple hopes that I’ll use it for Starbucks cappuccinos or for peer-to-peer cash payments (paying your co-worker for lunch) via iMessage rather than PayPal/Venmo. The execs at PayPal/Venmo just got served!

 

With all this, Apple is not only strengthening its ecosystem, but also adding another layer of moat around its active user base of 1.4 billion Apple devices (that include 900 million iPhones). The fruit company wants to make sure that the Pirates of Android can’t easily pillage its iPhone user base.

 

Financial Flywheel: Till about a month ago, Apple’s financial flywheel was “Wallet + 3P Apple Pay”. 3P Apple Pay here refers to the Apple Pay experience with credit cards issued by 3rd party banks such as Wells Fargo, Chase, BoFA, etc. These banks issue hundreds of millions of credit cards to consumers using their existing systems & processes – i.e. the business as usual incumbent model. With these old guard banks, Apple had limited control & innovation ability on the credit card experiences with iPhones/iPads. Now with a willing partner like Goldman Sachs, Apple can rethink & innovate the end-to-end credit card experience with iPhones/iPads – i.e. 1P Apple Card & 1P Apple Pay. Now, Apple’s financial flywheel is “Wallet + 3P Apple Pay + 1P Apple Card + 1P Apple Pay + Apple Cash Card + iMessages + your Checking Account”. Reeling in Apple Cash debit card into its payments flywheel is brilliant!

 

Overall, what was Apple’s approach & strategy with Apple Card?

It’s First Principle Thinking!

When launching a new product in an existing hyper-crowded segment, it’s very easy to fall into the trap of emulating others. Apple successfully avoided that trap with their First Principle Thinking:

  • What are customers’ pain points with credit cards?
  • How can I solve them better than others for my (iOS) customers?
  • What’s my differentiation from competition?
  • What’s my “unfair advantage”?
  • How do I ensure easy adoption & usage?
  • How do I weave it into my ecosystem and flywheel?
  • Who are my partner/dependencies? How do I choose them to serve my strategy?

 

The Apple Card experience is a reflection of that First Principle thinking. To execute on those vectors, with Goldman Sachs as the card issuer, Apple found a partner with the necessary financial gravitas who Apple could bend to their will and not be bogged down by incumbent thinking (i.e. this is how we have always done it). In fact, Apple’s official tag line “A new kind of credit card. Created by Apple, not a bank” reflects their First Principle approach to delivering a meaningful Apple Card experience!

 

Pareto Principle for Product Success

 

80-20

 

In late 1800’s an Italian economist named Vilfredo Pareto observed that 80% of Italy’s land was owned by about 20% of its population – the elite of the day. This concentration characterized by 80/20 distribution has now become the famous Pareto Principle (aka the 80/20 thumb rule). This 80/20 rule manifests itself in many areas of our day to day life. Some examples – for many non-fiction books, 80% of the main content is captured within the 20% of the pages, the rest is repetitive. For many companies, 80% of their sales income comes from 20% of their clients. In industrial environments, 20% of the hazards lead to 80% of the injuries.

Interestingly, this 80/20 rule can be used effectively to drive the strategy, execution & decision making when managing technology products & teams.

 

Product Market Fit: Most startups (& even established companies with emerging products) struggle for a while before they find their “market-fit” – i.e. they try pitching their product/service/technology in a variety of industries, verticals, use cases, price points, geographies etc. The lucky ones find the market-fit before the funding dries up and the no-so-lucky ones go belly up without ever discovering the market-fit.

It’s important to have a Go-To-Market strategy & target segmentation based on the attributes of your product/service. At the same time, during the discovery phase, it’s important to experiment & pitch your product for a variety of use cases – some of which should be outside your original target segment. If you are lucky, for every 10 attempts you make, you may find some semblance of market-fit in 1 or 2 cases (i.e. the 20% rule). VMware is well known for its virtualization technology. However, in the early days of VMware, they had to struggle for a long time to find the market-fit until their product landed in the hands of system administrators who were responsible for managing servers – the rest is history. To hear more about VMware’s early struggles, hear this interesting podcast interview with Diane Green (co-founder & former CEO of VMware)…

 

Product Usage: A typical technology product (software or hardware) contains many bells & whistles. My experience is (some anecdotal and some data-driven), most users (80%?) use a very small set (20%?) of the available features/capabilities on a daily basis. This provides a fantastic opportunity for product teams to derive amplified gains with minimal effort – identify the most used 20% feature-set and polish them to perfection leading to remarkable results! If your 20% feature set offers the best user experience possible, your users will love your product and think thrice before considering alternatives!

 

KPI’s: Product teams typically use metrics/OKRs/KPIs to measure & drive outcomes. These KPIs can take various forms like users, usage, transactions, customer satisfaction, NPS, repeat usage, DAU, MAU, geographical distribution, platform distribution, customer distribution, industry distribution etc. Depending on who you speak to within the company, the metrics list can be endless and it’s not practical to monitor and review all the metrics. A more practical approach to success would be to identify the top few metrics (the 20%) and drive those with a maniacal focus! Having fewer KPIs to monitor makes it easier for product teams to focus on those KPIs and drive the catalysts that grow those KPIs.

 

Key People in a Team: A typical product team (or a sub-team) consists of 6-8 people. If you are lucky, there is 1 person (i.e. 20%) who is a head-and-shoulder above the others on the team. If you are super-fantabulously lucky, you land a 10x person on your team. These are the people who can solve the prickliest of the problems or come up with ingenious ideas that take your product from mediocrity to superiority. Identify such key people and make sure that they are taken care of in every respect (i.e. compensation, assigning them non-mundane projects, protection from politics, etc.).

 

Innovation: Venture Capital companies are in the business of investing in innovative startups with the hope that they go IPO or get acquired. The reality is, for every 10 companies the VC’s invest in, about 2 of them find some success while the rest flop. Google is known as one of the most innovative companies with a string of “successful” products such as Search, Maps, Gmail, Chrome, Android, YouTube, Android etc. The reality is, 84% of Google’s revenue comes from its advertising initiative – the 80/20 rule at play again! Even successful companies like Google have to chase a variety of innovations before they can find a “hit”. What this means for corporates is, to drive innovation, you must have the willingness to stomach 8 or 9 losses before they can hit 1 or 2 successful products. Without this willingness to invest in losses, innovation cannot happen!

 

Use the 80/20 to find yourself 100% success!

2 Sided Drums & 2 Sided Product Innovation Model

 

Mridangam2

 

In South Indian Classical music (i.e. Carnatic style), Mridangam is the primary percussion instrument used to keep the rhythm. It’s a 2 sided asymmetrical drum made of a single block of hollowed jackfruit wood with the sides covered with goatskin membranes. One side of the drum has a larger opening that produces lower pitch bass sounds while the narrower side opening produces higher pitch treble sounds.

A masterful Mridangam player uses a combination of fingers & palm to play the notes – on one side or the other. But, when both ends are played, you hear a beautifully balanced rhythm of bass and treble sounds.

What’s playing a 2 sided Mridangam got anything to do with 2 sided Product Innovation Model?

A lot.

Typically product teams use feedback from different sources (customers, user research, sales & marketing, analysts, customer care, competition, etc.) to drive their innovation and roadmap. To me, that’s playing one side of the drum – delivering what’s being asked.

What about the unspoken customer needs (that can be addressed by applying a technology) – the other side of the drum? Are there any unspoken customer needs that can be fulfilled by bringing to bear technology enablers? Can the user experience be improved & refined above and beyond what users ask for?

 

Here are a few examples of such technology enablers:

 

  • Twilio: What if you had a SaaS platform that provides you an easy way of sending & receiving SMS/calls as a part of your product user experience? From within your product, can users quickly text themselves names, phone numbers, urls, pictures, etc.?

 

  • Zapier: What if you had a service that lets you stitch and automate workflows  between your product and commonly used services like gmail, google sheets, slack, twitter, facebook, etc.? Does the free flow of information across your product & other services make it easy for your users to consume your product functionality?

 

  • UserVoice: Every product team has one or more channels (email, web forms, etc.) to collect user feedback. What if the feedback volume is large? What if you had a structured feedback platform where your users can add ideas, vote on existing ideas etc. Check out Microsoft’s skypefeedback.com that uses UserVoice platform to manage its feedback loop for the Skype product. Can such a platform enable you to better manage your feedback loop and roadmap prioritization?

 

These are a few examples where the innovation conversation begins with a technology (and not a customer need) and teams figure out a way to meaningfully use that technology to solve a problem or improve a product experience – i.e. playing the drum from the other end.

So, how do you drive technology driven innovation to complement the customer need driven innovation? Here are a few ideas that worked for me:

 

  • Imitate & Improve: When you use different products, services, apps & websites as you go about your life, pay close attention to details. You will see examples of how different technologies are used to enable & improve user experiences. You could think about how to do the same in your products. Heck, I even get ideas from spam emails that land in my inbox! This is a very common innovation model in the tech industry – giants like Apple, Microsoft, Google, Facebook, Samsung, Uber, Lyft, Snapchat etc. often borrow ideas from each other.

 

  • Trade Shows: These are good places to learn about new & interesting technologies that can spark ideas on how you could use them.

 

  • Platform/SDK Capabilities: This is arguably the nerdiest model for driving innovation. Most products are developed using an underlying OS/platform/SDK. These platforms come with SDK documentation outlining the capabilities. Developers are usually the ones that read such documentation when coding – and that can spark a few ideas. Recently my Android product team stumbled upon the Places API for Android. They came up with an idea of using this Places API to make it easy for the user to quickly search for a place and use its address to automatically fill the address fields in a form. This improved the user experience of filling a form in a certain part of our product flow! This is a classic example of technology driven innovation rather than a customer need driven innovation.

 

Summary: The end goal of every product team is to address customer needs, improve product experiences and drive KPI. To do that, driving product roadmaps using technology driven innovation to complement customer need driven innovation can lead to well-rounded product experiences!

 

 

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!

 

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 6 vectors of evaluation:

1. Revenue/business Driver (or not): I don’t think this needs much explanation.

2. 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.

3. 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.

4. 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!

5. 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!

6. 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!

 

शेर गज़ल नज़्म & Jagjit Singh

 

jagjit

 

Preamble

5 years to this day, India’s best ghazal singer Jagjit Singh passed away. For me, there’s no discussion of sher-o-shaayari without invoking the memory of Jagjit Singh.

It was early 1980’s when I was in 8th or 9th grade. Living in Hyderabad/India, I would amble about the house while my father would listen to ghazal or qawwali. My next door neighbor Mr. Azam would wax eloquent about the finer points of Mehdi Hassan’s ghazals. At the cavalier age of 12 or 13, I couldn’t care less about ghazal-wazal!

Fast forward to 1987-88, I was in my first or second year of engineering college. I stumbled upon a cassette of Jagjit Singh’s album The Unforgettables from my father’s music collection. I was awestruck by Jagjit’s voice and that sparked my curiosity of Urdu poetry. By the time I finished my engineering in another couple of years, I had bought almost every album that Jagjit Singh released and most of his songs and their lyrics were etched into my brain for eternity.

Over the years I have heard most of the stalwarts – Mehdi Hassan, Ghulam Ali, Pankaj Udhas, Farida Khanum, Nusrat Fateh Ali Khan, Abida Parveen, etc. But, I kept coming back to Jagjit Singh. The reason was very simple – he always rendered the ghazal in a simple mellifluous melody. Even though Jagjit Singh was an accomplished Hindustani classical singer, he rarely engaged in any vocal ustadi (i.e. vocal virtuoso techniques like taankari) because he believed that vocal acrobatics distracted the listener from the ghazal lyrics. Jagjit Singh truly personified the bol-pradhan style of singing – he let himself be the invisible vocal medium while letting the lyrics of the shaayari take the spotlight. His choice of what to sing was also very deliberate – he chose easier to understand ghazals by poets like Qateel Shifai rather than the loftier ones penned by Ghalib.

So, what exactly is shaayari?

 

Shaayari – Sher, Nazm, Ghazal & Ruba’i

Quite simply, shaayari is poetry in Urdu language, while the poet is a shaayar. Here are some common forms of shaayari that have their own form and style:

 

Sher: It’s a two line couplet, a poem. A sher can be an independent poem or part of a larger ghazal. Think of a sher as a single lustrous pearl.

 

Nazm: A nazm is a freestyle form of urdu poetry with a lot less restrictions around the structure and rhyming pattern. A nazm can be 2 lines or a multi-line paragraph. The focus of the nazm is around the content and thought without much rigidity of the constraints. Given this freedom, writing a nazm is a lot less difficult that writing a proper ghazal.

 

Ruba’i: It’s a form of nazm that’s a 4 line poem. A collection of such quatrains is rubaiyat. The beauty of a ruba’i comes from its rhyming pattern where the first, second and the fourth lines share a rhyme while the third line breaks the monotony of the rhyme in the other 3 lines.

 

Ghazal: A ghazal is a string of shers (usually 5 or more) linked to a central theme. If a sher is a single lustrous pearl, think of the ghazal as a beautiful pearl bracelet with 5 or more sher. A ghazal is very structured with strict rules to follow – hence not very easy to write. Here are the 5 basic constructs of a ghazal:

  • Matla: The first sher of the ghazal. The two lines of a matla must end with radeef.
  • Radeef: It’s the common word(s) at the end of the first two lines of the matla. This radeef must also be used at the end of the second line of other shers in the ghazal.
  • Kaafiya: It’s the rhyming word that comes before the radeef. In a ghazal, all the kaafiya share the same rhyming sound.
  • Beher: It’s the meter of the ghazal – the length and the tuning pattern. A ghazal that doesn’t use a proper beher cannot be composed or sung musically. Writing a ghazal with proper beher that can be sung in rhytm, requires choosing words of appropriate length & rhyme while respecting the rules of a ghazal construct – a very difficult proposition. It’s not unusual for musicians & composers to occasionally make slight changes (the gustaqi) to lyrics (without changing the meaning) so that the lyrics fit the rhythm of the song.
  • Maqta: The last sher of the ghazal. It’s customary for a poet to use his takhallus (pen-name) in the maqta.

 

Here is a famous ghazal by the poet Mirza Ghalib:

 

दिल-ए-नादान तुझे हुआ क्या है

आख़िर इस दर्द की दवा क्या है

 

हमको उनसे वफ़ा की है उम्मीद

जो नहीं जानते वफ़ा क्या है

 

हम हैं मुश्ताक़ और वो बेज़ार

या इलाही, यह माजरा क्या है

 

जान तुम पर निसार करता हूँ

मैं नहीं जानता दुआ क्या है

 

मैने माना की कुच्छ नही ग़ालिब

मुफ़्त हाथ आए, तो बुरा क्या है

 

In this classic ghazal, क्या है is the radeef while the rhyming words वफ़ा दवा बुरा दुआ are kaafiya. In the maqta (last sher), the poet uses his taqallus Ghalib!

 

These are just the basic constructs and there are many more rules around writing a proper ghazal. With all these constructs and constraints, as you can imagine, writing a proper ghazal requires a firm grip on vocabulary, poetic aesthetic and even a musical sense.

Traditionally ghazals are written around love, longing, rejection, etc. But, at times, ghazals have a spiritual interpretation where the beloved is a metaphor for God. This duality in interpretation makes the ghazal even more sublime!

 

Homage

In the last 25+ years, for me, not a week has gone by without listening to Jagjit Singh. He invisibly accompanied me on walks, hikes, drives, on beaches, on buses trains and planes. With his music on my phone, he went everywhere I went – a constant companion. Over 25+ years I developed a je ne sais quoi relationship with Jagjit Singh – depending on what he was singing,  he was a a friend, a philosopher or a father figure!

I can think of no other way to pay homage to Jagjit Singh other than writing a ruba’i in his honor:

 

ना है तू यार

ना है क़ुरबतदार

फिर तेरे जाने पे

क्यों है हम ज़ार-ज़ार

 

I remember this as if it happened yesterday. On that crisp October morning 5 years ago, I dropped my kids off to school and went for a morning walk in the neighboring Ortega Park. While walking, I read on Facebook that Jagjit Singh had died. I lost somebody who was no friend or relation – but a constant companion over the decades. Slumped on a park bench, I wept like a baby!

 

Balancing Trains and Product Roadmaps

 

Balance to life is kale shakes and cupcakes!

– Unknown

 

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”!