Saturday, November 30, 2019

Ideas from 'Dreamers and Unicorn' Podcast between Abhijit Bhaduri and Pankaj Bansal


I recently had a chance to go through 'Dreamers and Unicorns' podcast on the subject of 'New code of work'.

Sharing some of the ideas i captured.

Podcast link: https://audioboom.com/posts/7408793-new-code-of-work-ft-pankaj-bansal

My Sketchnote Summary:




My notes:

Fundamental shift in last few years:Workplace is experiencing shift from plain automation to "can we put user at the center?"
Culture of the organization is at the center, which will come from employee and not from department.

Principles: New code of work:How can we bring more:
1. joy to work
2. energy to work
3. meaning to work

The new world of work is far more exciting
More flatter organizations
People can do what they wish to do

In the new world of work, Hierarchy is diminishing in the new world of work. There are squads who deliver a work and they move on.
Things that needed change in corporate culture

New code of the work is about being the design thinker or placing design thinking at the core of work.
If we do anything that is not helping the user in anyway, it is meaningless.

New code of work is bringing HR into the center and making it more than the enabler to the driver of joy, energy and meaning at work.

Money is a resource, nothing more nothing less.

Can an employee feel like an entrepreneur?
Build smaller enterprises within your company.

Technology should bring joy, energy and meaning to work.

About Employee experience:New world of work is always going to be about employee experience.

When we go to bank do we really want to go there to withdraw cash? We want digital systems like ATM to enable that.


Employees are no different. They don't want to meet someone to do the routine transactions. They don't want to feel controlled, they want to feel empowered, enabled.


Technology is not making lose human touch. It is empowering people to be themselves and be more productive.


Technology leads to more meaningful (less transactional) conversations between HR and employees. More about careers, less about payroll and leaves.

We need to empower employees so they feel the way they feel when operating Google or an automated banking operations or any other social media.

Human touch vs technology:Human touch is increasing, not decreasing.

Technology enables you to not forget someone's birthday but how you respond to that is human touch. (Either by walking up to someone or by sending digital card)

Technology and impact on recruiting:Recruiting in 3 buckets-
1. Sourcing candidates.
2. Processing the candidature of the person.
3. Getting someone onboarded to the organization

1 being done by bots, automated
2 undergoing changes, being automated
3 requires human touch

New recruiter will be talking to candidates and explain them what the job is, will be helping people get onboarded. That's the new role, not the traditional role.

Technology will remove the bias from recruiting and will help create "equal opportunity framework". It can help mask your gender, name, city etc. And then start the recruitment process.

Employees are demanding the same experience within the organizations as they get outside.

Types of systems:Monolithic systems (mostly designed for buyers)
Agile- user friendly, designed for users.
Agile system is the one which is molding itself for me. Bruce Lee said- 'Be water' my friends. If you put water it glass, it becomes glass. If you put it in cup, it becomes a cup.

Gig workers:Squads: come together for a purpose and disintegrate when the purpose is over.
Squads know no hierarchy. Hierarchyless world.
People are building systems that are hierarchyless and teams that are in squads


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

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