#pm tips

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.

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.

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

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!

The Jobs-To-Be-Done (JTBD) framework is one of my favorite tools in my product tool kit.  JTBD was created by Clay Christensen, a professor at the Harvard Business School, as a way to examine customer motivation. JTBD is a shift away from the "who," the persona of the target customer, towards the "what," an understanding of true customer need.  The core of the JTBD framework is customers buy things because they find themselves with a problem that they would like to solve.  "With an understanding of the ‘job’ for which customers find themselves ‘hiring’ a product or service, companies can more accurately develop and market products well-tailored to what customers are already trying to do," states the Christensen Institute.  If you are new to the jobs-to-be-done framework, I recommend you watch the classic Clay Christensen video, where he looks at why customers "hire a milkshake." 

One of my favorite blog posts about the JTBD framework is a piece on Intercom’s blog, "Designing Features Using Job Stories,” by Alan Klement.  The author argues that "Personas are imaginary customers defined by attributes that don't acknowledge causality."  I think there is still a place for personas and user stories in the product design and marketing disciplines.  After all, in order to market effectively it helps to know where your target customer is and what appeals to them.  When designing a new product feature though, more important than the who is the why.  New product features should solve a real problem for customers. Below are two helpful diagrams from Alan's article on the difference between user stories and job stories.

User Story

As a __, I want to __ So that ___

Job Story

When __ I want to __ So I can __