ProductCamp Austin 2017 — a few lessons
Recently many of us dedicated our Saturday attending and presenting at the biannual un-conference, ProductCamp. I personally am a conferences nerd. They can be focused on anything — education, health, environment, technology or products — good conferences have a welcoming vibe of sharing ideas and personal growth, with a bonus of getting to meet new people with similar interests. I enjoy panels, lectures, and listening to the perspective of other people. This weekend at ProductCamp was no different.
ProductCamp was right up my alley. It is a free, volunteer run conference to help participants build skills and expand product management and product marketing knowledge. I attended with the goal of gaining insights on the Product Management world, and to meet and hear the stories of others who showed up. After listening, below are lessons learned from four sessions of the 25 offered.
User Stories Suck! Upgrade From This Old Unnecessary Process
David Hawks, CEO, Agile Velocity
Main take-away — focus on discovery, not as much delivery.
Most of the Agile world is in the perspective of delivery focus. How do you know you’re building the right features? Businesses need customer collaboration and feedback, as stakeholder feedback is mostly opinion based. Teams use user stories to document requirements and to align expectations between stakeholders and the delivery team. But building features with the goal of satisfying stakeholders is not good enough anymore. We should be focused on satisfying the customer.
David brought this idea home by showing a video of a case study from Nordstrom Innovation Lab while the creative team designed a sunglass app. All feedback was user-centered/customer-centered in the store.
https://www.youtube.com/watch?v=szr0ezLyQHY
How to accomplish:
1. Ask what the objective of the user story. They are written from the user objective, but what is the business objective.
2. Write down top assumptions you have about your product and sort them high to low.
3. Conduct an MVPe (Minimal Viable Product Experiment) with the goal to shorten the learning cycle
4. Experiment — experimenting helps measure behavior, confirm and learn, and capture surprises
More information on the subject can be found on David’s blog -https://agilevelocity.com/article/user-story-needs-remodel-heres/
Secrets of Customer Discovery: How to Beat the Odds and Build Products that People Want
David Eckoff, Co-founder, Pickoff Sports; Advisor to media & technology companies
Main take-away — Risk is okay in businesses, unbounded risk is not okay. Think clearly of whether or not you have discovered significant authentic demand that can be met.
The mortality rate for new products and businesses is high. Over 50% of the businesses started today won’t last two years. David discussed practical set of actions to follow to improve your odds of building products people buy and use. He spoke about the importance of learning a customer discovery process, and understanding cognitive biases that can result in mistakes in assessing customer demand.
Goals:
1. Reduce building products that people don’t want
2. Engage in customer discovery process
3. Understand cognitive biases that can lead to mistakes
3 Step Framework:
1. Define as narrowly as possible who are your intended customers.
2. Define theories about your intended customers who you want to test — be open to what you are scared of hearing because it would mean that people don’t want your product
3. Quickly and inexpensively as possible, test your theories by conducting interviews with 20–100 people.
Twyla’s Design Sprint Journey
Douglas Ferguson, Founder and President, Voltage Control
Main take-away — Don’t sweat a failure or a failed win.
The idea behind a Design Sprint Journey is to build and test a prototype in five days, and is the brainchild of Jake Knapp of Google Ventures while designing Google Handouts. Knapp wrote a book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. The five-day design sprint’s purpose is to quickly find out how customers react before investing too much time and expense. Sprint has concrete examples and a guide for each process to help move forward on iterations.
Douglas was the facilitator this Design Spring for Twyla, The key is to have the proper team and a completely empty week. The team is to include at least a Decider, Facilitator, Designer, Graphic Recorder, Stitcher and more. The recruits are basically a team of everyone who is part of the process (CEO, sales, marketing, customer, designer, engineer, etc.)
The Sprint Funnel:
Monday — Map.
Map the problem, interview internal and external experts and confirm assumptions
Tuesday — Sketch.
Individual sketching to share ideas focused on the Sprint’s goals, target and questions
Wednesday — Decide.
Share, review and vote on individual sketches, then storyboard the prototype so everyone is aligned on workflow and experience to test.
Thursday — Prototype.
Collect assets, write copy, design screens and prototype using Invision, Marvel or other format so that the tester thinks it’s a real product interface.
Friday — Test.
Test one-on-one with five people in interviews, either personal or remotely, while the other members of the Sprint team observes from another room.
15 Ways Product Managers Can Improve Their Technical Skills
Dan Corbin — Sr. Director of Product Management, Return Path
Main take-away — most important skill for a PM is communication but technical skills are key
1. Collecting and analyzing data
2. A/B Testing
3. Spreadsheets
4. Prototyping
5. Increase your Vocabulary
6. Know your Databases
7. Coding
8. Version Control
9. Understand the Tech Stacks
10. Cloud Computing
11. APIs
12. Explore Emerging Technologies
13. SQL
14. Testing
15. Logging, monitoring and alerting
Dan shared his slides with the group including free resources for every category, many from Google, AWS, Udacity, Udemy, Code Academy and more.
https://docs.google.com/presentation/d/13zF3ELZuvPSRgLbsByUlgabuP5I6tLG1zkXZBQlwnbU/edit?usp=sharing
