Saturday, November 30, 2019

Ideas from 'Dreamers and Unicorn' Podcast between Abhijit Bhaduri and Anita, Harsha Bhogle


One of the books that inspired me years back was 'The Medici Effect (What Elephants and Epidemics can Teach us about Innovation)'. In the book, the author argues that innovation occurs at the intersection of diverse industries, cultures, and disciplines. Of all the fields, I find the learnings at the intersection of world of hashtagsports and hashtagwork rather fascinating. I recently had a chance to go through the 'Dreamers and Unicorns' hashtagpodcast between Abhijit Bhaduri and Anitha,Harsha Bhogle. For those who follow Cricket know that Harsha Bhogle is truly the voice of the sport. Podcast link: https://lnkd.in/fGews6i

My Sketchnote Summary:


Notes from the Podcast:

On Philosophy of life:Don't let what you cannot do interfere with what you can do. (Image: person talking "it's hard to do a marathon", counter voice "atleast take the first step"

Strive to stay relevant. We updated our book in the spirit of staying relevant.
Whatever you learn comes in very useful later. No skill is unimportant. (Image:

Be Versatile:What allowed me to be versatile was that i was not the best in world.


If i had 10000 runs behind me, i would have become this pundit and wouldn't have needed to learn and I would have become limited.


You have got no choice but to me versatile to survive.


A dear in a jungle has got to be versatile otherwise it would be someone's meal.

Adaptability:Have an open mind and learn from anyone around you- be it your kids or your younger colleagues.

The day you think you have arrived is actually when your descent has begun. You might be the best player in the world but the format might change, Are you still willing to learn ?
There are always signals, are you willing to listen ?

On Careers:Every 10 years you got to do something different.

If you have decided to do something in career, you decide to be best at it because you are giving up too much to it to be otherwise.


No one ever gives 100% to their second career, which I think they should. If you carry your experience in the first career as a banner, then you struggle in your second profession.

On learning from Sports:Biggest thing you learn from Sports is that you will fail. Everybody fails. The Giants fail. Everyone fails more often they succeed. It's what you do when you fail that matters.

Sports person never makes excuses. Given the playing conditions, a sportsman knows how to make most out of it.
You have got to be prepared for everything that comes. Make most of what comes your way.

In careers, you must try everything you can because very few people know what they are good at. Agassi hated tennis till he became a slam champion.


Try everything you can. When you find what you are good at, attack it with vehemence.

Tiger Woods and Serena were lucky because they found their passion early and were good at it. Not everyone does it.
In business, it is important to to be adaptable to genre you belong to.

On Coaching...Just like you need different leaders for different situations, you need different coaches fir different situations. Gary Kirsten asked Sachin Tendulkar- what he needs in a coach, Sachin said "I need a friend."

Sometimes people don't know how good they are. You need somebody to tell you, egg you on.
Very few people know how good they are.


Even the most successful people go through the crisis of confidence. Remember, that's just a phase and the best always comes back from that phase. There's always a another day.

How do we see feedback- as a criticism or an attempt to improve you?

On nurturing Children:We should let children play team sport. Whether it becomes a career or not comes much later. Collaboration will be so important in the gig world.

Children discover how good they can be only if they have fun doing it. You can't take fun out of anything you do.


My LinkedIn Post:
https://www.linkedin.com/posts/anujmagazine_sports-work-podcast-activity-6605417796778196993-Xo2s


My Twitter Post:
https://twitter.com/anujmagazine/status/1196818958562689024?s=20

Sketchnote Summary of the book: Ikigai: The Japanese Secret to a Long & Happy Life


Here's my #sketchnote summary of some of the ideas from the book-'Ikigai: The Japanese Secret to a Long & Happy Life'

#Ikigai translated to English roughly means"the reason for which you wake up in the morning"


The book has some implementable ideas,habit pointers on the subject.

My Sketchnote Summary:




Notes:
In Japanese, ikigai is written by combining the symbols that mean “life” with “to be worthwhile.”

Ikigai can be described as an intersection between 4 different elements: what you're passionate about, where your skills lie, how you can earn a living and what the world needs.

Hara hachi bu,” which is repeated before or after eating and means something like “Fill your belly to 80 percent."

Spend no more than twenty minutes on Facebook per day

“The grand essentials to happiness in this life are something to do, something to love, and something to hope for.” — Washington Burnap

“The happiest people are not the ones who achieve the most. They are the ones who spend more time than others in a state of flow.​”

“Concentrating on one thing at a time may be the single most important factor in achieving flow.”

“Being in a hurry is inversely proportional to quality of life. 

“We are what we repeatedly do. Excellence, then, is not an act but a habit.” — Aristotle

Never Retire

The Pomodoro Technique to FOCUS : Get yourself a kitchen timer & commit to working on a single task as long as it’s running.


My Twitter post:
https://twitter.com/anujmagazine/status/1193204169416433664?s=20


My LinkedIn post:
https://www.linkedin.com/posts/anujmagazine_sketchnote-ikigai-flow-activity-6607983669258874880-FKg2



Is Product (Management) hard ?

ag
Is Product (Management) hard ?
One could argue, without much disagreements, that most professions (if done right) are hard. So what's so specific about Product Management ? Marty Cagan delved deeper into this question for Product Management profession in his enlightening talk that i got a chance to go through recently. (My hashtagsketchnote summary below) What stood out for me in his talk was that it touched upon some not so oft-spoken aspects of the PM function. For example: Talk Video: https://lnkd.in/fzaegxs (~1 hour 50 min) htag
Slides: https://www.slideshare.net/mobile/AnthonyMarter/product-is-hard-marty-cagan

My Sketchnote Summary:


My notes from the talk:

People
DO YOUR HOMEWORK
- Most product managers don't do their homework.
- Product managers are not backlog administrators, they got to meet customers to be able to make decisions.
- Product managers should be seen as believable. They will be believable only if they meet customers.
- Do your homework and be smart to find people who can help you make decisions.
- if you don't know how various functions (sales, marketing, finance, contracts etc.) impact the product, then you are going to impact the various decisions up to CEO or some exec. If you can't take decisions, you are just a backlog administrator, not a Product Manager.


FOUR HOURS PER DAY REALITY
- You could be working like crazy but get nothing done.
- You cannot do a Product Manager job if you cannot spend four quality hours a day. No meetings, No distraction during this time.
- Technology often succeeds in interrupting us.
- Turn airplane mode on your phone to get things done.
- Get over the feeling that you got to be there in every meeting where your product is being hinted at.

HUMILITY
- Humility is so important in product. Recognizing your ignorance and doing something about it is a skill that is table stakes for a PM job.

Process- "Dual Track": Objectives-> Discovery -> Delivery
- Output (Feature) is different than a business result
- Discovery is all about tackling the risks upfront, not at the end. Four risks: Value risk (Will people buy it,
Usability risk (Can they figure out how to use it), Feasibility risk (Can we actually build it), Viability risk (Will it work for different stakeholders in the business). In product, our obligation is that the stuff our engineers build, addresses these risks i.e. is it worth building?
- Define collaboratively
- Outcome not Output
- Discovery: Try 10 different things for every one that works- Google
- Product managers should be measured on results, not on shipping features.
- Slide 7: Engineer risks vs PM risks
- If you use your engineers only to code, you are using only half their value. Engineers should be spending some amount of their time working with PM on discovery.
- One of the most motivating things you can do for engineers is to show them customers in pain.

Product:- Outcome based Roadmap: what would get improved if we execute this roadmap. Attach OKR, KPIs. Talk about the KPI Everytime you talk about the roadmap.
- Execs care about business results, roadmaps should lead us to that- not just the features.
- Good Product Managers understand the underlying constraints, not simply pass on the requirements.
- Pick the priorities that moves the needle.

Culture:- Lean canvas for your product.
- Understanding various elements of the business is a part of your homework.
- One of the key roles of a product manager is to ensure that engineers are excited about what is being built. They are a team of missionaries and not mercenaries. Share full business context with the team- like cost per customer, lifetime value, how much money is lost on every customer, economics of the business. It helps engineers and motivates them especially if it is difficult, which more often it is.
- No good innovation came because a customer asked for it. (No customer ever asked for Amazon Prime). One of the things about customers is that they are always unhappy, there's always more they need. And that's a good thing.
- As a Product Manager, be transparent about what you learn and share it.
- Hardest kind of Product Management is the platform because you have so many constituents, very demanding requirements.
- Most important thing in product- Knowing what you can't know- Marc Andreesen


My LinkedIn Post:

https://www.linkedin.com/posts/anujmagazine_sketchnote-productmanagement-activity-6603659689651736576-S7kt


My Twitter Post:
https://twitter.com/anujmagazine/status/1192111073941315585?s=20


Why it is important & what it takes to create API as a Product?


Recently, i took up reading the book: Continuous API Management: Making the Right Decisions in an Evolving Landscape

Currently, I am 1/4th through the book and enjoyed what I have read so far and found it quite relevant to what I am doing at work currently.

I am providing here, my summary and highlights from the chapter on the subject of API as a Product.

My Sketchnote Summary:




My Highlights from the chapter: (full credit to the authors: Mehdi Medjaoui, Erik Wilde, Ronnie Mitra, Mike Amundsen for the content that follow)

API is a product fully deserving of proper design thinking, prototyping, customer research, and testing, as well as long-term monitoring and maintenance.

Three lessons:
1. Design thinking in order to make sure you know your audience and understand their problems
2. Customer onboarding as a way to quickly show customers how they can succeed with your product
3. Developer experience for managing the post-release lifecycle of your product and to gain insights for future modifications.

Amazon's application of AaaP:Should You Apply AaaP to Both Internal and External APIs? Yes. Maybe not with the same level of investment of time and resources — we will cover that the next section — but this is one of the lessons Jeff Bezos taught us in “The Bezos Mandate” that led Amazon to open the initially internal AWS platform for use as a revenue-generating external API. Because Amazon adopted AaaP from the start, not only was it possible (e.g., safe) to start to offer the same internal API to external users, but it was also profitable.

Bezos issued a mandate that all teams must expose their functionality through APIs and that the only way to consume other teams’ functionality must be through APIs. In other words, APIs are the only way to get things done. He also required that all APIs be designed and built as if they would be exposed outside the company boundaries. This idea that “APIs must be externalizable” was another key constraint that affected the way the APIs were designed, built, and managed.

Applying Design Thinking to APIs:You can elevate your APIs from utilities to products by applying the principles of design thinking to your design and creation process.

It is important to remember that the results of design thinking are more than just improved usability or aesthetic appeal of your APIs. It can result in better understanding of the target audience (customers), a focus on creating APIs that meet viable business strategies, and a more reliable process for measuring the relative success of the APIs your team releases into the ecosystem.

Customer Onboarding:Stripe case study: Stripe is a successful payment service delivered via a great API that developers really love. The startup’s recent valuation was about $ 10 bn with less than 700 employees. The founders’ entire business strategy was to deliver their payment services via APIs. For this reason, they decided to invest in design thinking and the API-as-a-Product approach from the very beginning. For Stripe, the API was their only product.

Time to Wow:

In the API world, the time it takes to “get things working” is often referred to as TTFHW, or “Time to first Hello, World.” In the online application space this is sometimes called “Time to Wow!” (TTW).
In his article “Growth Hacking: Creating a Wow Moment,” David Skok, part of the equity investment firm Matrix Partners, describes the importance of a customer’s “Wow!” moment as a key hurdle to cross in any customer relationship: “Wow! is the moment… where your buyer suddenly sees the benefit they get from using your product, and says to themselves ‘Wow! This is great!’”
The effort it takes to reach a point where the API consumer understands how to use the API and learns that it will solve their important problems is the hurdle each and every API must cross in order to win over the consumer.

Apple Analogy:

just as Apple makes sure the battery is already charged up when you open your new mobile phone, media player, tablet, etc., APIs can be “fully charged” at first use, making it easy for developers to get started and make an impact within minutes of trying out a new API.

So, a great onboarding experience is more than just the result of a good design process. It includes well-crafted “getting started” and other initial tutorials, and diligent tracking of API consumers’ use of these tutorials.

Developer Experience:Even though it is important to make sure the product “works right out of the box,” it is also important to keep in mind that the customer will (hopefully) continue to use the product for quite a while. And, over time, customers’ expectations change. They want to try new things. They get bored with some things they loved at the beginning. They start to explore options and even come up with unique ways to use the product and its features to solve new problems not initially covered by the product release. This continuing relationship between consumer and product is typically called the user experience (UX).

Know your audience:

A big part of creating a successful API as a product is to make sure you target the right audience. That means knowing who is using your API and what problems they are trying to solve.
By focusing on the who and what of your API, you not only gain insight into what is important, but you can also think more creatively about the how of your API: what it is your API has to do in order to help your audience solve their problems.

API Discovery:

One of the challenges of API programs at large organizations is that, even when an appropriate API is available, developers end up creating their own APIs.

Searching for APIs: there is no single, commonly used public search engine for APIs.
Suggestion: At least one company we talked to made publishing to a central discovery registry a required step in the build pipeline. That meant the developers building an API could not actually release it into production until they’d added it to the company’s API registry and ensured all important APIs within the organization would be findable in one location — a big step toward improving the discovery quotient of their API program.

API Error reporting: Error reporting is a great way to get important feedback on how your API is being used and where problems occur. But it is only half of the tracking story. It is also important to track successful API usage.
API evangelist Kin Lane puts it: “Understanding [how] APIs will (or won’t) assist [the] organization to better reach their audience is what the API( s) are all about.”

Making APIs safe to use and Making APIs easy to use.


My LinkedIn post:
https://www.linkedin.com/posts/anujmagazine_api-sketchnote-activity-6600795750291079168-ni4E

My Twitter post:
https://twitter.com/anujmagazine/status/1195008850803322886?s=20

Monday, October 28, 2019

Sketchnote: 20 Years of Product Management in 25 Minutes by Dave Wascha


While scrolling through a lot of Product Management content in the last few days, i came across this presentation by Dave Wascha that I found relevant.




It was one of those presentations that sticks with you. It was one of those presentations that excited me enough to create a sketchnote of (that i share below). Here are the summary of points tthat Dave shared:

1. Listen to your customers
Your job as a PM is to maniacally focus on your customers problems.
You cannot solve customers problems without understanding it.
If you don't listen to customers, you end up creating solutions for the problems no one has.

2. Don't listen to your customers when it comes to solution
Your customers are least qualified people when it comes to solution.
Listen to your customers when it comes to problems but don't listen to customers when it comes to building solutions.


3. Watch the competition
When a competitor launches a new feature, I view it as a user test that I can learn from.


4. ...but don't watch the competition
It's too easy to simply follow the competition into building something shiny, even though it might not be the best solution.


5. Be a Thief
Your job is not to come up all the best ideas, but to make sure you're implementing the best one for your customers.


6. Get Paid
Don't forget to ask the most fundamental question- is this valuable enough for customer to pay for it ?


7. Speed Up
Every time you put off a decision, you are destroying value. It's our job to remove obstacles and make sure that decisions are made- and made fast.


8. Say No
Our job is not to make people happy- it's to solve our customers' problems. Say No often to competing priorities.


9. Don't be a visionary
Products need product managers who are obsessed with solving customers problems and who put in the hard work to grind it out and solve those problems. I have been forged in a white hot heat of failure and I am a better product manager because of that.

Sketchnote Summary of the Talk:








Tuesday, October 15, 2019

How do you measure progress of your Innovation work ?


Most Innovation teams (atleast the ones that I have led) typically have hackers in the majority. I dislike generalizing things but by and large what I have observed is that hackers tend to fall in love with solution. Now this doesn't necessarily mean that they don't love the problem but it's just that the focus on solutions just keeps them interested and going.

Irrespective of whether the teams are led by hackers or hustlers, one of the hardest things in managing Innovation work, especially the ones in early stages, is determining a way to measure the progress. Early stage innovation projects are the ones that are at the ideation phase or haven't achieved product-market fit.

Lean Start-up approach (that I normally follow in running Innovation programs) suggests an effective framework for solving the progress/measurement problem. There are several approaches that I have successfully applied, part of which you can read here.

Recently, I got an additional perspective on measurement of progress. The insight I received was while reading the book- 'Jugaad 3.0- Hacking the Corporation to make it fast, fluid and frugal'. Here is the related excerpt:
"Intuit Founder Scott Cook is a big believer in what he calls "love metrics"- which might sound soft but can actually be assessed with some precision.
- How much do people actually love idea of the product ?
- Did they recommend it to their peers ?
- How often do they come back ?
These kinds of measures can be more than sufficient to confirm a team's hypothesis or prove the need for a course correction."
Notice that the questions suggested by Scott Cook aren't ground-breaking, neither do it belong to 'never heard of before' category but what stands-out in these metrics is the focus on empathy. The fact that Scott chose to call this "love metrics" make it look so distinctive. After all, aren't we all in the business of delighting the end-user, in the endeavor of making users fall in love with our offerings.
That's why I really loved the insight Scott shared here.

The book also quotes a blogpost from Vijay Anand, also from Intuit Labs. Vijay says:
"When the team asks me if something is a good idea, I ask them for their unit of one- the one customer their product will delight. And once that works, I tell them to bring me 100. When 100 delighted customers actively use a product, I know there's something to it."
Profound. Isn't it ?

So, what's the unit of one  for your idea ? And what love metrics are you tracking to measure their happiness with your offering ?

Image source:
https://www.amazon.com/Jugaad-3-0-Simone-Ahuja/dp/0670090832?SubscriptionId=AKIAILSHYYTFIVPWUY6Q&tag=duckduckgo-d-20&linkCode=xm2&camp=2025&creative=165953&creativeASIN=0670090832

Tuesday, October 8, 2019

Corporate Talk: The mindset of an Intrapreneur


Had a privilege to present in front of young, talented employees of Qapitol couple of weeks back. When my friend Ajay Balamurugadas reached out to me for a possible talk, one of the first topics that
came to my mind was on Intrapreneurship.

The reason this topic is dear to me is for a few reasons:
1. Intrapreneurship is quite an under-rated and under-leveraged concept in the corporate world.
2. I had a recent stint as an Intrapreneur and created opportunities to create more intrapreneurs in my organization.
3. I believe that the young audience (which Qapitol team was) should get introduced to Intrapreneurship as early as possible in the career.

I have used the term 'Intrapreneurship' a few times already and some of you made me wondering what this term actually means. Let me narrate the essence of Intrapreneurship as follows:

About Intrapreneurship:
Entrepreneurship has been a buzzword that dominates most of the conversations in our industry. Entrepreneurs are certainly a special lot who are ultra-passionate, enjoy taking risks and are usually driven by making a positive impact to the world around them.

With all the attention that entrepreneurship gets, it is arguably not possible for all of us to become one. There could be myriad of reasons for this but many of us consciously find our calling in working for the organizations. If an entrepreneur creates a vision, it's the employees who make it a reality. So this choice is absolutely fine and legitimate.

Being an employee doesn't mean that you cannot exercise the traits that make one an entrepreneur. In my career journey, I discovered that one can embrace those traits anytime at work and create a dent in the universe surrounding your organization. Simply put, Intrapreneurship is the act of behaving like an entrepreneur while working within a large organization.
In this session, I shared my experiences about this discovery of mine and dissect a few of the distinguishing qualities that make one an Intrapreneur.



About the mindset of an Intrapreneur:
In the talk I focused majorly on the mindset of an Intrapreneur. I ran my first full marathon (42.195
Km) in 2014, focused a lot on physical training. Realized at the end of that run the importance of mindset training. Recently, finished my 17th  full marathon in 40 degrees plus heat, could finish it due to better mindset preparation.
I follow similar approach while taking any new roles i.e. unpeel the job and figure out what mindset would be needed for success and work to master that first (while working on skills).
In many ways, mindset training precedes skills training.

Here is what I talked about as being an mindset of an Intrapreneur.

1. Intrapreneurs have high degree of situational awareness
2. Intrapreneurs know how to build support for their idea
3. Intrapreneurs know how to effectively communicate success
4. Intrapreneurs are authentic, align first with core values
5. Intrapreneurs are champions at connect the dots
6. Intrapreneurs focus on Credibility/Reputation first, Skills next
7. Intrapreneurs embrace learnability, but also stay teachable
8. Intrapreneurs know that asking for help is not a sign of weakness
9. Intrapreneurs understand that there is absolutely no sense of entitlement
10. Intrapreneurs know how to embrace constraints
11. Intrapreneurs come to work willing to be fired
12. Intrapreneurs keep the hunger, that ‘Fire-in-Belly’ alive at all the times
13. Intrapreneurs show-up more often than anyone else

In the upcoming blogs, I would double-click on each of these aspects and share a bit more details from my experience and a few analogies from the world of sport.

Presentation:
https://www.slideshare.net/amagazine/the-mindset-of-an-intrapreneur-v12-26th-sept2019-slideshare

References:
Jugaad Innovation: A Frugal and Flexible Approach to Innovation For The 21st Century