Guest on Usetpilot YouTube channel in prep for 2021 Product Drive conference

In preparation for my upcoming session on Userpilot’s 2021 Product Drive conference, I had a chat with Emilia Korczynska, Head of Marketing @ Userpilot.

What is the difference between Product Led, Project Led, Sales Led and Solution Led? Why do so few companies understand what Product Led *really* means? When is a feature solving a problem and when are PMs simply coming up with problems to solve? Why are so many B2B platforms catering to 10 different personas and only solving one problem for each rather than trying to achieve higher product adoption with fewer user personas?

Listen to the full interview to find out the answers.

Check out my session on Product Drive and register today: https://summit.productdrive.io/speakers/moshe-mikanovsky/

https://www.youtube.com/watch?v=DBvSDivbpqA

Top 5 Product Manager Technical Skills in 2021

Original published at UserPilot’s Blog, April 2021

If you’re an aspiring or a junior product manager – technical skills are something that will give you a massive leg up in your career. Moshe Miklanovsky, a Software Developer-turned Product Manager and a co-host of the Product-for-Product podcast, explains which technical skills are essential for Product Managers based on his 30-year career in tech.

Product Management is a very young profession. Compared with software engineering, which started sometime in the 70s, not long ago Product Managers were a part of Marketing departments, and usually handled activities such as Go-To-Market, pricing, competitive analysis, and messaging. It is with the advancements of lean methods and agile cultures for building software products that the modern Product Manager was born.

But where have Product Managers come from?

In some surveys, it has been found that about 50% of Product professionals come from software development backgrounds, while the rest are from different disciplines such as business administration, customer support and more.

Still, many hiring managers are looking for a technical background or know-how for their Product people, and in truth, there are some benefits in having such skills.

So, which technical skills should Product Managers have in 2021?

The #1 Product Manager Technical Skill: SQL

What is it?

Pronounced “ess-que-el”, it stands for Structured Query Language. SQL is the language developers use to manage and interact with relational databases, such as Oracle, Microsoft SQL Server, Postgres, and many more. The engineers would usually define table structures, indexes for fast queries, and any number of procedures to insert, read, update and delete data from the system. This is one of the building blocks for many systems.

Why would a Product Manager need it?

A cornerstone of understanding how our product is doing with the intended user base is to understand the usage of the product. This information, in many cases, is found in the database.

For many product managers, this technical skill may be needed if there is no tool that provides this data in a structured way. In these cases, either we get the developers to get the data for us (and take away from their time to improve the product), or we find it ourselves, using SQL query statements.

Can I succeed without it?

Yes, but you will need other ways to access your data.

One option is to ask developers – which means they would need to spend valuable time fetching data for you rather than improving the product. A better way would be if there is a data mining tool that presents the database in a more user-friendly way so that you don’t need to run SQL queries. There are many tool options, though they bear their own cost and learning curve.

What do I need to know to use it?

First, of course, you will need to know the language itself. It is not difficult to learn and there are many resources online and courses as it is part of the curriculum of every software development program. You also don’t need to learn everything. The minimum knowledge is the SELECT statement – getting data from the database.

Second, you’ll need access to the database. It is a good idea for product managers to get Read-Only access. We shouldn’t mess with the data.

And lastly, and with the most complexity, we need to understand the specific data structure of the database that holds the data for our product. This can be simple in small or new products, but very complex in others.

If you spend time with the engineers, rather than getting them to run the searches for you, get them to teach you how the data is structured. It will mean the difference between just getting data and getting the right data.

The #2 Product Manager Technical Skill: HTML/CSS

What is it?

HTML (HyperText Markup Language) is the language that all web pages’ content is built with. CSS (Cascading Style Sheets) defines how this content appears on the page.

Why would a Product Manager need it?

Many products are built with web technology, and it can be very useful to know how these pages are structured. This can be helpful in situations such as:

  • Pages are inconsistent across the product
  • Changes to page components are tested on the fly – this can be done with the development tools of the browser you are using
  • Using tools such as product analytics or A/B testing that take their cue from the page element. When setting these up, it is usually based on the HTML or CSS elements that define the page

Can I succeed without this technical skill as a product manager?

Yes. Although very useful, a developer can always come to the rescue when we stumble upon such a need.

What do I need to know to use it?

First, the structure of an HTML and CSS page. It is useful to know which tags HTML supports and what each means. For CSS it is handy to know how it is structured and used in the web application. There are many parameters that CSS can have to control all aspects of the page, so don’t worry about knowing all of them.

Within the browser you are using, it is useful to know how to inspect elements and find their definition in the HTML code, and if you want to go further with that, how to manipulate them on the fly to see changes on the screen.

Product Manager Technical Skill: #3: JSON

What is it?

JSON (JavaScript Object Notation), pronounced like the name Jason, is a way to structure data in a simple text format. It is easy for humans to read and write, and easy for machines to parse and generate.

Why would a Product Manager need this technical skill?

There are several places where JSON knowledge can be useful:

  • If your product is not built with a relational database, where you can use SQL to query data (see above), but rather with NoSQL databases such as MongoDB or Couchbase, you will not be able to use SQL. In these cases, you will usually have to format your query using a JSON structure. In addition, the data stored in the database is usually returned as a set of documents, each structure in a JSON format as well.
  • Many products have a layer of APIs (Application Programming Interface) used to encapsulate functionality that is then called from other layers of the product. In some products, the APIs are also exposed to the world, being another product of its own, which is consumed by developers of other products. As product managers, it is very useful to know how the encapsulation of functionality happens in product architecture, as we can think of different ways to use it, as well as testing on their own.

Can I succeed without it?

Yes, especially if your product does not include NoSQL database, nor has external facing APIs. But even then, it can be good to know of its existence, as knowing the possibilities can always open up the door to new options.

What do I need to know to use it?

The JSON format is quite easy to learn. What might make it more complex is the information it could contain, as it is limitless, but that really depends on its application in your product.

For APIs, as well as NoSQL databases, check with your developers what structure to use. They can give you examples, or even templates, as well as documentation.

Product Manager Technical Skill #4: Technical Stack and Product Architecture

What is it?

The Technical Stack is the technology of all layers that comprises your product. These are usually 3rd party products that your engineers decided to use in order to build the product. It also includes the technical environment that the product is hosted on, which affects how it’s deployed and promoted to the users.

The Product Architecture is the breakdown of components that comprise the product, usually developed by the engineers.

Why would a Product Manager need it?

There are many reasons to know the technical architecture of your product.

As a product manager, you are not responsible for defining or building it, but you will find that having that knowledge will make you a better team member.

For example:

  • Understanding what the engineers have to deal with to build the product will give you empathy towards their challenges and complexities, and will help your communication.
  • Every architecture decision will have pros and cons and will impact your product, and therefore your customers and the company. You must consider how the technology handles performance, security, scalability, and supportability. Cost is another aspect of the technology used and the product’s architecture.
  • The technical stack, and more specifically, the environment it is deployed to, impacts the ability to provide constant product updates to users. This can make the difference between releasing a new update every day (or several times a day) to once every six months.

Can I succeed without it?

Yes, but you will greatly rely on your team’s engineers and DevOps to provide you with the issues and challenges of the selected stack. The good thing is that you don’t need to know the technology in-depth, only at a very high level.

What do I need to know to use it?

Not much! Talk with your engineering team to learn what comprises the technical stack and product architecture. Ask why each component is needed, and how they are all related to each other. Be curious about it, and ask them to explain it in a non-technical way. This will be a great exercise for them as well. I find diagrams that show the entire architecture very useful, as they put everything together and usually give a good understanding to non-technical people.

Product Manager Technical Skill #5: Specialty Technologies

What is it?

Many products rely on special technology for the entire solution to work. These are always part of the Product Architecture mentioned above, but it is worth mentioning them on their own as they are used in very specific types of products. These could be things such as AI (Artificial Intelligence) and ML (Machine Learning), AR (Artificial Reality) and VR (Virtual Reality), IoT (Internet of Things), and many other technologies.

Why would a Product Manager need it?

On top of the reasons mentioned above, specific technologies like these can impact your product discovery and delivery. As there are many unknowns (such as in AI/ML case) or interactions between software and hardware (such as in IoT), developing a product with these technologies can be very different from developing more traditional products.

It is important to know how these technologies work, what their limitations are, and what is required to put them together so that we can better understand how they all impact the product throughout its lifecycle.

Can I succeed without it?

Yes, although here too, you will greatly rely on your team’s engineers to provide with the issues and challenges of the specific technology. This might hinder your ability to make proper decisions about your product. It might also frustrate you if you are only familiar with traditional software technology, and expect things to work the same.

What do I need to know to use it?

Learn about the technology as far as you feel comfortable. You don’t need to have a deep understanding, but it is a good idea to have an overview of what it is, how it actually works, what it takes to put it together, what type of problems it is good for, and what its limitations are.

Determining The Product Management Technical Skills You Need

So, do you need every technical skill outlined above?

It depends. If you have the technical help from your team, or tools that can help you achieve the same results without a deep dive into the back end, you could have a sufficient understanding of your product without the need to hone additional technical skills. If on the other hand, you are short on both resources, some of these skills might be very useful in your toolbox.

Remember, at the end of the day, your job as a Product Manager is to build a product that provides value to your users and works for your company. And sometimes the road to get there is paved with technical needs. In any case – getting some technical skills in product management won’t harm you!

5 Virtues Product Professionals Should Master to be Successful

These are 5 virtues product professionals should master to be successful

Virtue #1: Patience

Why do we need it?

As we are dealing with many unknowns, inventing new things, discovering new solutions to old/new problems, we go through an unpaved road. That road will guarantee to throw at us many curves, some potholes, dead ends and even a landslide or two. Without patience we would give up early and get nowhere

A few examples where we need to be patient as Product Managers:

  • Finding product-market fit
  • Getting everyone around us to understand what product management is and how to do it right
  • Finding enough users to talk with and get useful feedback
  • Listen to users go through their journey and their experience POV
  • Experience failures and persevere to find success

Can we develop patience?

I think we can, once we know we lack it:

  • First, be mindful about it – ask others: “am I patient?”
  • Practice starting small. Hold my thoughts and listen. How do I feel while doing it? Can I wait for others to finish talking or do I have an urge to speak without waiting my turn?
  • How do I feel when I fail? Am I discouraged quickly or have a drive to try the next thing?
  • Practice daily with small things, grow a habit, and then continue with bigger things
  • Record every success!

Virtue #2: Empathy

Why do we need it?

Our main job as product managers is to build a valuable product for our users while it works for our company. Without empathy to both – users and stakeholders in our org – we can’t really do our job.

A few examples where we need to be empathetic as Product Managers:

  • Understanding our users’ journey
  • Looking for their problems & JTBD
  • Understanding the impact of the product on our team members that will need to support it
  • Understand how UX and UI impact the users
  • Understand technical challenges our engineers face and what it takes them to build the product

Can we develop empathy?

I think we can, once we know we lack it:

  • Remind myself that others have different POV/job/interests/knowledge
  • Be humble that I don’t know everything
  • Look for opportunities to learn about other people
  • Join support calls to see the pain
  • Use the product to feel the pain
  • Sit by users/stakeholders to see how they work
  • Mentor other PMs to help solve their issues

Virtue #3: Curiosity

Curiosity is the engine that drives scientific research – inquisitive thinkers observe behaviors in complex systems, define hypotheses and drive conclusions from what they find. They see problems and find solutions. In essence, product management is very similar

When are we curios?

  • Finding problems to solve
  • Talking with users to understand their jobs to be done and which problems they have in the current solution
  • Exploring technologies and new ways that can be useful in solving problems
  • Understanding how our company runs and makes money, which regulations/restrictions apply, and how it affects the product we build

Can we develop curiosity?

I think we can, though it is much easier when we are passionate for what we do:

  • Ask “Why?” constantly. The more we ask, the deeper we get
  • Construct gut feelings/assumptions as hypotheses, and develop a process to prove or refute them
  • Define the desired end result and find a way to get there
  • Create opportunities for observations – find where our users are and join them
  • Create mind maps that open opportunities for deeper insights/directions

Virtue #4: Trust

The last virtue I want to add to the previously discussed Patience, Empathy and Curiosity, is Trust.

Where do we need trust?

  • From our c-level/leaders to empower us to build products that provide value to the users while working for the company
  • Our teammates, designers and engineers, to work as a team towards the same goal/outcome, while each do our utmost best to reduce the risks that are in our domain (value, usability, feasibility and viability)
  • Our customers, paying hard earn money to use our products to solve problems they have, and not create new problems
  • Trust the data, not people’s opinions

How do we develop trust?

People say that trust is not given but earned. I would argue that when a person is hired to do a job they are given that trust in good faith. Yes, we need to prove we have it (that’s what 3 months probations are for, no?) but good faith is a two way road, so managers have to provide the trust to allow it to happen. So what can we do?

  • Over communicate all the time, be transparent
  • Don’t be shy of hard discussions
  • Don’t just talk the talk but walk the walk
  • Provide data asap
  • Deliver outcomes

Virtue #5: Respect

Where do we need respect?

  • Respect our customers and users to listen to their problems with *empathy* and really understand what their needs are
  • Respect everyone’s time and commitment, as they *trust* us to deliver them some value, and are *patience* with us to deliver it
  • Respect diversity of voices, expertise and experiences so that we can develop our *curiosity* to learn from each other

Can we develop respect?

Hopefully, all of us already have it as we are growing up from childhood to adulthood, and our parents and teachers show us by example, as well as teach us what respect means. If we still don’t have it, or we are not mindful about it, we could do things to hurt others.

Being mindful about it is the first step to all the virtues I discussed, but respect is the one that probably captures them all. When we practice the other virtues, respect will be developed as a welcomed side effect.

Guest on the Experiment Nation Podcast with Jaya & Sid

Under the hosting of Experiment Nation, a community that seeks to connect all those who are interested in experimentation including Conversion Rate Optimizers (CRO), Product Managers, Growth Managers, Analysts, Researchers, UX designers, and Marketers from around the world, I chatted with Jaya Gupta and Siddharth Taneja about the importance of getting closer to data by getting familiar with data tools.

https://experimentnation.com/2021/04/10/product-experimentation-a-chat-with-moshe-mikanovsky-about-building-competency-and-fluency-with-data-part-2/#.YHySRxNKgWo

10 Tips for Product Prioritization

Product prioritization is one of the hardest things to do in product management. That’s why I tried to tackle it on a regular basis, as it is like a muscle that needs constant practicing. I hope the following tips will be helpful!

Note: I originally published each of these tips as a short video on LinkedIn. At the end of each tip below you will find a link to watch the video post.

1 Identify the Product Vision

I’ve seen companies developing products without clear vision for what the product should be. This creates a lot of confusion and chaos in making prioritization decisions. If we can’t tell where we want to be in the future, how can we decide on the details to get there?

The vision should be a long term look at where you want to get with your product. There are different ways to define your vision, but think about 5 years from now, or even 10 years. Don’t be afraid to think big!

Last, but not least, your product vision should be derived from the company’s vision. If they are not, again you will find miss-alignment and chaos.

Watch video

2 Define the Strategy

Strategy is the way to get to your vision in broad-strokes. There are many ways to get to your vision, and you probably cannot try all of them at once. Pick up the specific ones you want to try, and that will be your strategy.

The strategy could cover different goals for your product, so it’s okay to have multiple strategies for different areas.

The best set of articles I have seen about Product Strategy were written by Gibson Biddle, former VP/CPO at Netflix/Chegg, “How to Define Your Product Strategy“.

Watch video

3 Look at quantitative data

When you need to prioritize between different competing product features, look for relevant data on each one of them. This will help you identify which one is more urgent to do, or fitting better your vision and strategy.

Quantitive data is the one that comes in quantity – many users, interviewees, survey respondents and actual user activity in your product will provide data on what they use, what they like and what not, etc. Use this data to drive insights into what is important to people and make decisions accordingly.

There are many ways to collect quantitative data, you just have to do it. Look at it daily and drive insights from it. I’m a big fan of Pendo.io, but don’t forget your SQL or NoSql databases if that’s your only source. Your BI team and data warehouse should be your best friends. Look for data everywhere!

 Watch video

4 Look at qualitative data

Qualitative data is the second type of data you should look at to help you make prioritization decisions. Qualitative data is the one that comes in the form of comments from people. You can collect it via surveys using open questions, user interviews, usability testing done in person, feedback via customer support or success calls, sales calls etc.

The trick with qualitative data is to collect it from all the different resources, and drive insights from it. There are several systems out there that help with that. I don’t have a specific one to recommend at this time, but maybe in the future.

Watch video

5 Get stakeholders’ buy-in

This is one of the tricky ones, but it’s very important. There are no two stakeholders alike, and getting their buy-in is not a science. You need to talk their language, tell them a story they relate with, have empathy to their needs their Job-to-be-Done.

Try to:

  • Socialize with them outside of the work meetings. Get to know them as people and build your rapport with them.
  • Keep them in the loop regularly. Keep things transparent, including the reasons for making the decisions you made.
  • Show them the data! No one can argue with that.
  • Show them how product decisions align with the organization’s vision and strategy.

Watch video

6 Learn different ways to prioritize

There are so many ways to prioritize, and you might been doing one or more of them, even without knowing their “official” name. Some are quite intuitive, while others are more complex and need to be learned.

The best resource I found for prioritization techniques was written by Daniel Zacarias, who put together on his Folding Burritos site “The Periodic Table of Product Prioritization Techniques“. Check it out, you will love it too!

Watch video

7 Experiment

You should experiment with different prioritization techniques, as not all of them will work for you, and you might find one or two that makes the most sense for your case.

Extermination also goes for different product ideas and/or product solutions that you and your team comes up with. Not every idea is a good idea. You should find quickly and cheaply (a) if the problem is real, and (b) if the suggested solution will work for the users. Once you experiment you will find the qualitative and quantitate data you are looking for to make an educated decision!

A great resource on experimentation is the Strategyzer book “Testing Business Ideas: A Field Guide for Rapid Experimentation” by David Bland and Alexander Osterwalder. Don’t let the name confuse you – building a new product is just like testing business ideas.

Watch video

8 Keep a balanced product

This idea comes from Adam Nash, ex-VP of Product & Growth at Dropbox. The idea is that you want to keep your product balanced between 3 areas: Metric Movers, Customer Request and Delight. Usually requests or ideas from each of these areas will not overlap also into the others, and to keep your product balanced you need to develop from each of them on a regular basis.

You can read more in Adam Nash’s presentation Be a Great Product Leader, (Amplify October 2019) on SlideShare

Watch video

9 Think Product-Led

Product-Led means that the product is in the centre of everything. You want the product to sell itself, and give your prospective users ways to make these decisions without a lengthy and expensive sales cycle. You also want them to promote the product for you. To do so, Product-Let organizations would provide things like: full-featured free trial period to try the product in it’s fullest, self-served training and on-boarding to help user learn the product quickly, amazing UX and beautiful UI to make the product easy and fun to use, etc.

All of the above determine prioritization decisions as you will need to provide specific functionality to support it.

You can learn more what Product-Led is all about by checking Wes Bush and ProductLed for articles. Also, Todd Olson from Pendo.io released the “Product Led Organization” book recently.

Watch video

10 Prioritize all the time

As product managers we prioritize our backlogs on a regular basis, but there are other things we should prioritize all the time:

  • Our daily activities. We are like jugglers with lots of balls in the air. We must prioritize these so that we don’t drop anything.
  • The features and requests coming in. Don’t wait for the last minute. Keep a prioritized list and use the prioritization method that works for you to add these in the right place.
  • The long term roadmap. Work with your stakeholders and make sure the roadmap is up-to-date and still aligned to your vision and strategy.
  • When things don’t work – Pivot. Pivoting is important as you don’t want to get stuck with previous bad decisions, and when you pivot your entire prioritization will change.

Watch video

I hope you’ll find these tips helpful! Please let me know if you have additional tips for Product Prioritization.

Ready, Set, Read: Starting a PM Book Club at Your Organization

Originally published on Product Craft, October 20, 2020

Are you looking for a way to transition your org to a more product-focused mindset? I wouldn’t blame you — there are numerous benefits to shifting to a product mindset, from becoming truly Agile to transforming into a fully-fledged product-led organization. But how do you do it?

Here is one idea that can help: Start a product book club.

Step 1: Invite everyone

Since you want the product-mindset transition to happen throughout the organization, invite as many people as you can from different departments, groups, and teams. You will want to include stakeholders, engineers, QA, UX/UI designers, customer success, sales, you name it.

If your organization is very large, sending an open invite will diminish the effectiveness of this initiative. Pick a select group that will really drive change: individuals whom others listen to and true leaders who are motivated and humble enough to learn new things.

Most importantly, make sure that your close teammates and key stakeholders are included.

Remember: You can also start small and iterate later with additional books, all while learning from the experience.

Step 2: Pick the best product books

It’s always good to have book recommendations, and even better to have your own favorites. For my book club, the first one I picked was Marty Cagan‘s Inspired: How to Create Tech Products Customers Love. In it, I found what you should look for in your first book:

  • Concise
  • Written in a clear and simple way
  • Covers all the basics and more
  • Not a 1000-page totem

Once you finish the first book, you will be in a better position to dive into additional books that cover very specific angles or areas of Product. Todd Olson’s The Product-Led Organization: Drive Growth By Putting Product at the Center of Your Customer Experience is one example if you want to focus more on, well, product-led organizations.

Remember: There are so many great books out there. Picking those that most resonate with you and your organization will make the book club a success!

Step 3: Purchase the book for everyone

You want to make it easier for everyone to attend, so don’t wait for them to purchase the book. Instead, buy it for them. Find a budget line where it could fit — education, lunch and learn, you name it.

Don’t forget to ask your participants about their preferred book format. Many of us still like physical printed books (yes, the way it feels in our hand … sometimes how it smells … it’s a full package!) so order in bulk and have it shipped to the office. If most people are working remotely, send it directly to their homes.

Digital formats are a bit trickier since consumers have to order them using their names/accounts. I haven’t found a way to bulk-purchase e-books yet. For those who prefer an e-book, send them the Amazon (or another online bookstore) link to purchase it and keep nudging them gently to buy the book. Give them an Amazon gift card to buy it, or make it expenseable.

Remember: You want to make sure there are no excuses about not being able to get the book!

Step 4: Publish a reading schedule

A reading schedule is important. It will determine the cadence of your progress and the amount of reading between each discussion meeting. You want to make it fast enough so that you keep good momentum, yet slow enough so that everyone has a chance to read the required pages while maintaining a busy schedule.

I found that a good cadence is around 50 pages a week, and aligned with the book’s chapters or other logical breakpoints. Take the book you have decided to read and look at the Table of Content. Try to break it down so that every week you read the number of pages decided (such as 50, plus-minus), and see how it aligns with the chapters. During some weeks, you might have to read a few extra pages, while others might be a bit lighter.

Once you have the breakdown, publish a schedule on your favorite calendar application and invite the book club members. The invite should include:

  • The book you are reading
  • The meeting cadence
  • The page range to read each week
  • What they should bring with them to the meetings (see next step)

Set it up a couple of weeks in advance, while making sure that everyone got their book copies, so that they have time to read the first part.

Remember: The book club is not everyone’s first priority, so don’t expect them to read as you might. Keep the schedule simple and realistic.

Step 5: Ask everyone to bring quotes

I’ve tried many different ways of conducting book club discussion meetings. The one I’ve found that works the best and covers the most ground is to ask everyone to bring quotes from the section they read that week. To encourage participants to gather these quotes, tell them to highlight while reading and take a screenshot or a photo of the page on their phones. Then, bring these to the meeting. It’s even better if they send the quotes beforehand and you upload them all into a shared document or presentation.

Most importantly, bring your own quotes and assume no one else will bring theirs. It will help you run the meeting and cover the aspects of the book that you wanted to discuss.

Of course, you won’t be able to address every aspect of the read section during the meeting. But the quotes will focus your discussion around the parts of the reading that are the most important and the most applicable to your team’s interests.

Remember: Being ready for the discussion meeting is two-thirds of the work to make it successful!

Step 6: Meet weekly and discuss what you read using the quotes everyone brought

Generally, I’d suggest a weekly cadence for the meetings to keep things moving. If you meet more often, it can be hard to maintain the reading speed. Meeting less frequently might mean participants forget what they talked about in the last meeting, especially if you had to stop in the middle of a section.

My preference for meeting time is over lunchtime, and even better if lunch is served. We all know that where there is free food, more people show up. Try to sense if they came for the food or for the learning. That could be easily done by asking them questions about the book and seeing who participates.

Most importantly, keep the book club discussion centered around the quotes. If possible, go through them in the order they appear in the book. As the facilitator of the discussion (or if you named someone else to facilitate, make sure they do the following), encourage everyone to:

  • Share opinions about the quotes or other relevant learnings from the book
  • Ask “why” to drive additional observations
  • Think of times when the specific topic of discussion was applicable to their work. Stories from your past and present shared experiences are the best way to apply learnings.

Remember: Keep the club friendly and open to everyone. Encourage participation, and not just from the same people again and again. It’s a learning opportunity for the entire team, no matter their individual perspectives.

Step 7: Ask “How can we improve based on this?”

This is the one question you should always ask. Reading a book is not about finishing the pages or consuming the information. It is about learning and growing. We must try to apply the learnings to our own life to facilitate growth.

So always ask, “How can we improve based on this?”

It can be small or big improvements, immediate or long-term. It doesn’t matter as long as we grow, and doing it together is the point.

Remember: Always ask, “How can we improve based on this?”

Step 8: Celebrate the completion of each book

Finishing reading a book together is always an achievement. During the weeks we read and discuss the books, there will be interruptions, and some discussion meetings will likely have to be delayed due to unforeseen circumstances. Some areas of your team will be so different from what the book recommends that you might think it is impossible to change.

Don’t fret about those small setbacks. Keep going with the book to learn and grow together. And when you have finished it, celebrate. Have lunch together — one without reading and discussions — just for fun. Or play a game. Or do whatever you like doing to celebrate both small and big wins.

Remember: It’s all about small steps that when taken together, make a huge difference. Now that you completed a book together as a team, you have shared knowledge and understanding about the topic, as well as a list of action items to improve your team. That is a huge win!

Step 9: Choose your next book

Don’t lose the momentum — keep reading. Bring a few options to the team and vote on which book they would like to read next. Or pick the next one, too. Either way, don’t stop after one book. There is so much more learning to be had!

Remember: Other team members can take over replacing you in the organization and facilitation of the club. It doesn’t always have to be you.

Final thoughts

A few final thoughts for you:

  • Have fun! Maybe some people don’t enjoy reading, but don’t make it into a chore. Try to have fun with it. Suggest audiobooks if they are available. Or maybe discuss the book with them beforehand so they have the details even without reading.
  • Did a specific book resonates strongly with your entire team? Make it your bible. Refer to it on a regular basis. Keep quotes on your (virtual) walls. Study it again and again.

Do you want to share how this idea works for you? Send me a line on my LinkedIn profile. I would love to hear from you.

Guest on the Techstory Podcast with Doug Thompson

A podcast interview with Doug Thompson, on the Techstory Podcast.

Doug really knows how to ease you into the discussion, and I enjoyed chatting with him about my background and how trying to be an artist influenced my career in product management.

Doug had a long career with Microsoft and recently started a new adventure, which he documents on LinkedIn with some posts. He also have live sessions, so lots of interesting content and opportunities to learn from him. If you are not following yet, please do!

Check the podcast on all the podcast platforms or right here.