Analog Girl in a Digital World

I build products! This page is where I chat about the products I build and what I’ve learned. Here are a few of my favorite topics to write about: My Notes PM Tips Maker Log Analytics

[gemmacurl]

5 Great Resources for Preparing for PM Interviews

Peace ya’ll, I decided to explore new PM opportunities a few months ago and sought out resources to help me study and prepare for PM interviews. Below are a few of my favorite resources that I used to prepare:

Websites

1. IGotAnOffer.com- This website is a great resource with sample questions from various product companies.

2. TryExponent - This online course covers typical sections of PM interviews for top tech companies. If you’re cheap like me you can skip the course and watch their youtube videos.

3. Lewis-Lin.com does a great job of breaking down how to answer tough PM interview questions. This is a great way to get the abbreviated version of tips from Lewis Lin’s book listed below.

Books

4. Decode & Conquer - Lewis C. Lin - An awesome resource with sample answers to example PM questions.

5. Cracking the PM Interview - by Gayle Laakmann McDowell & Jackie Bavaro - A thorough resource that covers the typical areas of product management that are assessed in interviews.

In terms of results, I received multiple offers from great companies after using these resources to study and strongly recommend them.

Full Disclosure: The book links are affiliate links so if you buy them I will get a few coins tossed my way. I did read these books though and honestly recommend them.

[gemmacurl]

Maker Log - Black Epics 1 Pager

Hey ya’ll, I’m extremely excited about the newest product I’m building, Black Epics, a podcast dedicated to shining a spotlight on successful Black Product Managers. I took a step back and wrote a 1 pager on the podcast when I first started working on the idea. You can view the 1 pager here if you’re interested in learning why the podcast was created.

 Let me know your feedback and if you’re interested in checking out the show you can listen to episodes here.

[gemmacurl]

PM Tips - My Favorite Google Analytics Resources

I recently saw a question on the Black Product Manager Slack Network about how to ramp up on Google Analytics. Anybody that has worked with me knows Analytics tools are near and dear to my heart so I thought I’d share a few of my favorite Google Analytics resources

Google Analytics Academy - This is a great free resource for beginners that are just getting started. 

Justin Cutroni’s content- Justin is an Analytics Advocate at Google and has written the Google Analytics book on O’Reilly books. The books can serve as a good bridge between beginner and intermediate level GA proficiency. You can also check out his blog for a variety of great GA content.

Simo Ahava’s blog - This is a great resource for more advanced topics such as Google Tag Manager tag organization, slack integrations, setting up analytics testing, and much more. 

[gemmacurl]

My Notes - Takeaways from Product Hunt Interview w/ Slack VP Ethan Eismann

Hi folks,

I really enjoyed listening to an interview with Slack VP, Ethan Eismann, on the Product Hunt podcast. The focus of the conversation was how to design products that delight your users. Below are a few quotes that stuck out to me:

Brianne Kimmel - To be a very successful B2B product now you really have to bring in all of those wonderful aesthetics that consumer facing products have been doing for a while but have been missing from the enterprise space.

One of the most revolutionary points in the experience of software design was with OS X. With that launch we had movement incorporated into the base operating system that millions of people were using. Prior to that animations and motion weren’t even part of the consideration of the experience of computing and Apple really pushed forward with that.

There are some universal principles for product design and development. I don’t think of these as just product design principles. I truly think of them as the way of building products whether development, design, data scientist or product manager.

Make it simple every step of the way

Put your customers first and really focus on solving their problems

We’ve started developing some best practices for prototyping:

Make sure we have an environment to support it e.g. tech stack to allow us to update aspects of a design and test it w/ live code and data w/n hours.

Enrolling engineers and treating them as if they are designers in the process.

We always make sure we have a hypothesis for our iterations.

We believe in documenting our learnings. We ideally are good librarians of past experiments.

It’s ok to try wild ideas because sometimes wild ideas yield the best results. We have things we really didn’t think would succeed and we did it anyway to understand the impact of what that design might be and what the experience might be.

Pushing the boundaries of what we think is practical and reasonable gives us greater confidence that the direction we’re choosing is the right direction.

When you’re able to prototype in a really low cost way and your engineers are enrolled with the process and you’re ok with pushing the boundaries you’re not just learning about the right path you’re learning about the wrong path which gives you greater confidence about the wrong path.

In addition to that it’s important to be patient with the process. It can be messy and you sometimes loop back to where you started. That can feel chaotic and messy but that’s ok.

Prototype with your end users and not just your team.

It gives you better information by actually talking to your customers and you know what they need and how they respond to the prototype

It can actually develop a much deeper connection with your customers.

How does one as a maker bring an element of delight in their own unique way?

First and foremost put your customer first.

Second, bake the notion of delight or making your experience more pleasant into your mission which should inform your brand.

Then what’s critical is prioritizing hiring someone who writes with tone and personality and make this person one of your early hires. You need a maker to shape the voice and not a manager.

I definitely recommend you listen to the full podcast here. If you give it a listen let me know your thoughts.

[gemmacurl]

Maker Log - Created MVP for Product Hunt Makers Fest

With many conferences being forced to go virtual due to Covid-19, I decided to create a website that aggregates online conferences. This was an interesting project to me because for the past few years I've been wanting to attend several product tech conferences  but haven't found the time or prioritized figuring out travel arrangements with a small child. I'm excited for the opportunity to now attend conferences virtually that I couldn't in the past and hope to share these conference with others. Whether you are looking to up-skill professionally or been impacted by Covid-19 layoffs and looking for opportunities to network, I hope this list of conferences can be helpful to you.

In terms of technical implementation, I thought about building this with No-Code since the idea is pretty simple and doesn't really need code for an MVP to validate the idea. I'm hoping to improve my React skills over the next few months though so building this app in React would help me "feed two birds with one scone."

I hope you will check out Virtual Confs at http://www.confs.online/ and let me know your feedback.

[gemmacurl]

My Notes - Iddris Sandu Interview on the "Your Attention Please” Podcast

Hi folks,

Wishing you all health and happiness in this time. Something that really gave me joy recently was listening to an interview with Iddris Sandu on the "Your Attention Please” Podcast. I wanted to share a few quotes that resonated with me on the podcast:

I’m always prepared because I’m always constantly reading…That constantly means learning and sometimes unlearning.

Steve Jobs quoted Alan Kay in the 2007 launch of the iPhone when he said, "To build great software you have to create great hardware and that’s what inspired the creation of the iPhone."

These kids need platforms that were designed for them.

If I’m getting credit from a biased platform that wasn’t built for me where does that get me, because credit means validation.

No more waiting for a seat at the table. If you get to the table and there’s no seat bring your own.

You can be a creative but you have to be a business person. You have to be branded as a creative CEO.

Ownership means nothing if you aren’t coming back to your community and making other owners.

I definitely recommend you listen to the full podcast here and if you have Hulu watch the Your Attention Please episode with Iddris Sandu.

Cheers!

[gemmacurl]

Maker Log - “Product Show & Tell” Lean Experiment Follow-Up

I didn’t follow-up on this experiment but needless to say, the two success criteria defined were not achieved. Still, I consider this experiment a success.  I have a goal this year to experiment more and do so with an open acceptance of failed experiments. More failed experiments can still mean success as long as I’m trying new things and learning from those experiments fast. As Thomas Edison once said, “I have not failed. I have just found 10,000 ways that won't work.” The quantity of experiments is important but more important to me is the speed of my feedback loops. I think this is the key differentiator from those that try a lot of things that yield no results and those that try a lot of things that succeed. 

[gemmacurl]

Maker Log - “Product Show & Tell” Lean Experiment

I’ve been thinking about a new side project I can work on but want to ensure that I don’t spend a lot of time building something that people wont use. It’s so easy to fall into that trap on my side projects even though it’s completely opposite of how I like to build products as a Product Manager during my day job. Maybe this is due to a side project being just that, something that you work on for fun on the side. Since it’s just for fun, it’s easy to take shortcuts on lean product development best practices and just jump into building. Despite it being a fun project, I would like it to be useful so I’m performing a lean experiment to validate the opportunity.

The Opportunity

I love reading Product Management articles but I always have to go to a variety of places to find good content. Some of my favorite places are MindtheProduct, ProductTalk, and the Intercom blog. Feedly helps to aggregate my favorite sites but I would like a standalone solution dedicated to Product Management articles so that I don’t get pulled into the rabbit-hole of the other topics I follow. In addition, I would like for others to be able to contribute content since my feed only contains sites that I’m familiar with. It would be cool to create a community around the best product management content from all around the web rather than just the best content I’m aware of. With that in mind, the opportunity that I believe exists is to create a place that aggregates the best product management content from product managers around the globe.

The Lean Experiment

The lean experiment I’m performing is to create a list of Product Management resources using https://lystof.com, a site that allows you to easily drop articles into a list, collect subscribers, and allow others to contribute to the list. The nice thing about using Lystof is I won’t have to build anything for the experiment and I can test two key assumptions: 

1) People are interested in seeing quality Product Management articles from around the web in one place

I will consider this validated if in 2 weeks I have 20+ subscribers to the list with minimal, free marketing effort which will include sharing on a few PM slack channels, Twitter, Reddit, and IndieHackers.

2) People are willing to contribute Product Management articles.

I will consider this validated if in 2 weeks I receive content submissions from 10 different people. There’s a risk here that people are willing to initially submit content but not continue to submit content over time but that seems less risky than these two assumptions that must be true for this idea to be successful. I can perform another experiment in the future to validate that people are willing to continuously submit content. 

Kick-Off

Now that you have some background about the lean experiment I’m conducting which I’m calling Product Show & Tell, feel free to follow along. The Product Show & Tell list was created here on 10/17: https://lystof.com/list/H1uJV9Utr/product-show-and-tell

So far, the list has been shared on the Product School and Women in Product slack channels along with IndieHacker.com and Twitter.

I’ll share an update in a week with a mid-point update on how the experiment is going.

Alright yall,

Peace

[gemmacurl]

My Notes - Achieving Extraordinary Results with Ordinary People Talk

One of my goals this year is to consume more product content, whether that be in the form of books, talks, blogposts, etc. As a way of committing the information to memory, I would like to write summaries of the content and post the summaries here. My hope is these summaries will also be valuable to you. With that said, here is my summary of Marty Cagan’s, “Achieving Extraordinary Results with Ordinary People” talk at Productized.

Product Discovery - rapid series of experiments, primarily using prototypes, that enable us to discover effective solutions to the problems our team is tasked to solve

There are 4 big risks in product

Valuable - Will it be valuable?

Usable - Will people buy it/choose to use it?

Feasible - Is it feasible do we know how to build it?

Viable - Is it viable for the business? Does it work for the different parts of our business?

Empowered Teams

Marty Cagan’s Top 10 books on empowered teams:

Principles - Ray Dalio

Work Rules! - Laszlo Bock

The Culture Code - Daniel Coyle

Legacy - James Kerr

Creativity, Inc. - Amy Wallace and Edwin Catmull

Start-Up Nation, The Story of Israel's Economic Miracle - Dan Senor, Saul Singer

Turn the Ship Around! A True Story of Turning Followers Into Leaders - L. David Marquet

Extreme Ownership, How U.S. Navy Seals Lead and Win - Jocko Willink and Leif Babin

The Art of Action: How Leaders Close the Gaps Between Plans, Actions and Results- Stephen Bungay

Team of Teams - General Stanley McChrystal

The key is trust!

What are the differences?

What Do These Companies Have in Common?

The founders of Amazon, Apple, and Google were all coached by Bill Campbell, the "Coach of Silicon Valley"

"Leadership is about recognizing that there’s a greatness in everyone, and your job is to create an environment where that greatness can emerge." - Bill Campbell

Leadership vs management

“Leadership serves to inspire people to greater accomplishments, and management exists to motivate them to the objective.” -Mike Fisher and Marty Abbott

The Role of Leadership

Product Vision - Our north star, typically for software 3-5 years out and for hardware 5-10 years out. If you have 50 product teams in your company. This is the common objective. This is our best recruting tool. It's the purpose.

Product Strategy - How do we get from here to this great vision. Intelligent intentional choices about what problems we attack and in what order.

Product Principles - The nature of the kind of product we want to create, things we believe to be true, inform the decisions we will make when conflicts come up

Product Priorities - These get teams to focus

Key Pitfall - separate teams making separate objectives, success requires product leadership to define organizations objectives

Product Evangelism - We need teams of missionaries not of mercenaries - John Doer

Good product people know what they don’t know, what they can’t know, and admit what they don’t know

The Role of Management

Staffing - Put in place competent people

Coaching - Develop people

Objectives - Set team level objectives

The Basis for Trust

“Trust is a function of two things: competence and character. Competence includes your capabilities, your skills, and your track record. Character includes your integrity, your motive, and your intent with people. Both are vital. “ - Stephen Covey

“No Assholes Rule” by New Zealand All Blacks, most successful sports franchise across all countries and all sports for 100 years. It doesn’t matter how talented a player or coach is. They will not hire someone who is an asshole.

The True Test of Empowered Teams

The team is staffed w/ competent people w/ character, covering the necessary range of skills.

The team is assigned problems to solve, and they are able to decide the best way to solve those problems

The team is accountable for solving the customer or business problem (outcome)

Ordinary People

Ordinary People do amazing things when they work in an environment that lets them to do amazing things

[gemmacurl]

PM Tips - Improving My User Story Acceptance Criteria

A lot has changed since I last wrote a post. I've started a new Product role at Pivotal Labs. I've also been building small Rails apps now that I've completed the Agile Development Using Ruby on Rails (ADUROR) course* on edx. I’m thankful that my new job began right at the completion of the ADUROR course because many of the practices recommended by the course were modeled after how my current company works. The course put strong emphasis on how behavior driven development and test driven development can be used together to create software solutions in a world of uncertainty. To do this effectively, it is recommended that you write customer-friendly user stories with acceptance criteria in the Gherkin language. I was familiar with the customer-friendly user story portion but the Gherkin acceptance criteria was new to me and I would like to share what I learned about that particular portion of the user story. 

So what exactly goes into Gherkin Acceptance Criteria? Let's create a hypothetical user story that we can use for the rest of this breakdown to explain the components. Let's imagine you are in the early stages of building an app that tracks ice cream trucks so that you know how far away they are and can plan for their arrival (since those quarters won’t round up themselves). The app is in the app store and users have started providing feedback that they want the ability to save their favorite icecream trucks so that they can differentiate them from the other trucks on the map. You’ve performed some research on this idea and have validated that this would be a valuable feature. Here’s how to approach creating the user story. First, you can write the traditional user story, where you explain the user value this feature provides. This is the standard "As a____, I want to ____, so that ____” format. If Job Stories are more your speed feel free to substitute in a job story. In our example, the user story would be: 

As a user, I want to save favorite icecream trucks, so that I can see a heart marker that differentiates my favorite trucks from the other trucks on the map

Next you can write the Gherkin acceptance criteria. This section should play out like a well-written movie. The scenario is clear, the action occurs, and then there are results based on the action. You want to explain the scenario by starting with “GIVEN." Next you want to explain the action by  starting with “WHEN." Lastly you explain the result by starting with “THEN."  If you want to elaborate on any sections you can add “AND" to provide additional information. Let’s put it all together for the user story we’ve been building:

Given I am logged in And I have visited the “Map Screen” When I click the “favorite" button next to “Mr.Swirly’s” name in the truck list  Then I should see a “favorite heart" icon above Mr. Swirly’s truck on the map

From a Development perspective, I’ve found the benefit of writing Gherkin acceptance criteria is I have to really understand the full user experience for a story prior to writing a single line of code. From a Product standpoint, writing Gherkin acceptance criteria forces me to clearly outline the scenario, user actions, and results that users see in response to their actions. I used to write acceptance criteria for a QA team in the form of a checklist of items that must be verified in order for a story to be ready for acceptance. I see much more value in explaining acceptance criteria in a way that a test suite can validate and working in a process where the tests are written prior to the user story being developed. The creation of the tests prior to the code ensures that there is clarity about what success means and there are constant checks of new features against old tests to ensure nothing has been broken. This leads to better code quality and a more stable user experience. QA can co-exist with this way of working if that’s a role within your company. This introduces more time for the QA team to focus on use cases that have not been covered by automated testing, traffic surges, and device variations. I’ve found that writing Gherkin acceptance criteria has had the unexpected benefit of leading to more clarity, not just for computers, but also for people who are manually reviewing a story for acceptance. Writing user stories may seem like a tiny part of being a product manager so it can be easy to rush through them but they are extremely important. Writing clear, thought-out stories can lead to a lower story rejection rate which will hopefully lead to a higher velocity. The result is also a higher quality application for the end user. I challenge you to approach your stories the way SaltBae approaches cooking— with care and precision.

Do you write your user stories differently and want to share your best practices with me? Please reach out to me using the links to the upper left. I would love to hear about your personal experience with user stories. Are you curious about trying the format I just described in your next stories? Let me know how it goes and if you run into any issues. *Note- The course I mentioned above is “Agile Development Using Ruby on Rails (ADUROR)” on edx.

[gemmacurl]

New Year MVP

It's a new year so that means it's time to accomplish that resolution of building that product you always wanted to create. Before you jump too far in, make sure to take some time to validate your idea. I was reading "Idea to Paying Customers in 7 Weeks: How We Did It" by Joel Gascoigne at Buffer and there was a quote by Eric Ries that really stood out to me. Joel mentions that, "In Ries’ guide to Minimum Viable Products, one of the key things he answers is “how minimal should your Minimum Viable Product be?”. Here’s his answer: Probably much more minimum than you think.

Think about that sentence for a minute. Whatever features you think your product needs are not necessary to validate that there are potential customers out there and that they would be interested in buying your product. It's so easy to fall in love with an idea and all of the amazing features that you have in mind. It's also easy to build something and then find out people don't want to use it. In the words of Steve Blank, "An MVP is not a Cheaper Product, It’s about Smart Learning."

When you feel yourself going down the path of jumping in to building a complex v1 product, just pause and think about that Ries quote. Then go back to the drawing board to create a simple test to validate your idea.

[gemmacurl]

I’m Back!!!

Hey folks, It's been a while since I wrote a blog post. Sorry for the hiatus but sometimes you have to really lock in on a single goal to get it completed. I mentioned that I was going to take some time to learn ruby on rails and I'm excited to say I've completed the "Agile Development Using Ruby on Rails" course on Edx. The course was an awesome reminder of agile principles and an in-depth overview of Ruby on Rails Behavior Driven and Test Driven Development. Now that I've finished the course, the real fun begins.  It's time to start bringing my ideas to life. I'm also hoping to spend more time writing blog posts now that my development course has been completed.  Please check back soon for new blog posts about product management.

[gemmacurl]

#NP - What Motivates People to Buy

Today I listened to a short podcast about Jobs to Be Done on MegaMaker. The podcast had an interview with Alan Klement discussing what motivates people to buy. Alan also discusses his recently launched book, When Kale and Coffee Compete. Craving more than a short podcast? You can watch the full video interview on youtube below:

If you would prefer the podcast, you can listen to it here.  Alan’s new book, When Kale and Coffee Compete is also available for free download here. Have any suggestions of other great product podcasts or books, send me a message using any of the channels listed on the left.

[gemmacurl]

PM Tips - #PMGoals

You may have heard about #LifeGoals and #RelationshipGoals well today I want to talk about #PMGoals. #PMGoals are skills you want to develop so that you can become a better Product Manager I’ll kick things off. My goal is to become more inquisitive and ask better questions so that I can get better answers. Why is this important? Asking questions can be the difference between building something that addresses your users needs and building something that only you find interesting. Also, the true answer to your question is often not provided by the first response from users. In fact, a lot of research has been performed on how many questions it takes to get to the root problem and 5 is often considered the magic number. The “5 Whys” technique was formally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies. 

The “5 Whys” are particularly important during user testing. When you ask users about their pain points with your product they may start out with a few feature suggestions. If you dig into the feature suggestions and ask questions about why they want those features and what problems they will solve, you may uncover new problems that have a variety of different solutions which may be different from the features they originally requested. Many PMs love the Steve Jobs quote, “A lot of times people don’t know what they want until you show it to them.” 

Another popular quote is that of Henry Ford, “If I had asked people what they wanted, they would have said faster horses.”

I believe both of these quotes are true, but although people don’t usually know what they want, asking more questions can help to understand what problems they are facing and what jobs they are trying to accomplish. In Henry Ford’s quote for example, if you asked a user who rode horse and buggys what they wanted, they would have said faster horses. If you asked why they wanted faster horses, they may have provided more insight into why they need to go faster, how fast the user hopes to get to their destination, and why their current horses don’t go faster. These answers by no means would have provided you with the technical solution that Henry Ford developed. That’s where the PM magic comes in. You have to be able to take all of your user’s problems and come up with solutions that address their problems. Many of these solutions may not be what the user envisioned until you show it to them, as Jobs quoted.

Now you know why I’m working on building up my curiosity and why I encourage fellow PMs to do the same. What are your #PMGoals? Are there certain skills you hope to develop so that you can take your PM skills to the next level? Please share them with me via my contact information on the left of the page. In closing, I’ll leave you with a quote and a song.

Quote:   “People think they need the answers. They don’t need the answers they need the right question.” - I heard Tim Ferriss mention this quote a mentor shared with him in one of his recent podcasts.

Song: Mos Def - The Questions

[gemmacurl]

PM Tips - Oh, the Places You’ll Go with Product Discovery

Product Discovery is one one of the most exciting parts of Product Management. It’s where you take the time to determine what to build to provide customers with value. In the ideal situation, product discovery shouldn’t be performed in a waterfall like approach where you have one phase of learning and a second phase of development. Instead, the focus should be on learning as much as possible, as efficiently as possible, by testing out ideas with real customers. On paper, a product idea can sound foolproof and bound to resonate with customers. In actuality, products don’t always get the reception we expect. As a Product Manager, it’s important to understand that our bias is always present and use a combination of product discovery techniques like customer interviews, a/b testing, and lo-fi/hi-fi prototype user testing to name a few methods. I really enjoyed watching this case study of how Nordstroms performed Product Discovery that I found on ProductTalk.com.  It was great to see how they received real customer feedback so fast.  Check it out and let me know your thoughts!

[gemmacurl]

You’re The Real MVP!!!!

My husband shared this image with me the other day and it put a huge smile on my face for two reasons. One, the infographic embodies the phrase “a picture is worth a thousand words, and two it made me happy just to know that my husband knew this image would make me grin like a giddy school girl.

The term MVP (minimum viable product), is thrown around frequently in the product community.  Eric Ries, author of “Lean Startup,” helped popularize the term which refers to the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.  As product managers, we have to be careful not to use the term MVP as an excuse to release a product prematurely.  That’s not how the MVP was intended to be used.  As the infographic illustrates, putting a wheel up for sale as a way of determining if a user would be interested in purchasing a car will not yield accurate learnings.  An MVP should have the features necessary to allow you to quickly collect feedback while still providing users value. For that reason, when thinking about an MVP, consider the Minimum Valuable Product that can be built.  By going down this path, you will hear your customers yell out, “You’re the real MVP.”

[gemmacurl]

It’s Been A Long Time

Shouldn’t have left you Without a strong rhyme to step to - Eric B. and Rakim

Hey folks, I know it’s been a while since I posted so I figured I would share an update on where I’ve been. I decided to learn a new programming language so I’ve been spending most of my nights and weekends learning Ruby on Rails. That means I’ve been drinking a lot of caramel macchiatos and spent very little time thinking about blogging. Hopefully that will change soon (the not blogging part) and I can share some updates and sample apps I’ve built with you.  In the meantime, feel free to hit me up with any pm questions or to share advice. I’m always looking for ways to become better at what I do.  With that said, time to get back to these tutorials.