Startup Product Management 101

Editor's Notes

1. Good morning. Thanks for attending Denver Startup Week. Welcome to Startup Product Management 101. I’m Matt Hubbard, and I’m a Product Manager at FullContact here in Denver. This session will last approximately 45 minutes, and we’ll save 15 minutes at the end for Q&A. I will also be available afterwards for any questions that don’t fit into the Q&A.
2. PM for 3.5 years. First official PM at FC. 1 year of support & marketing. No prior technical experience. Lawyer by trade.
3. PM for 3.5 years. First official PM at FC. 1 year of support & marketing. No prior technical experience. Lawyer by trade.
4. Cloud address book for iOS, Android, Mac, Web, and Gmail. We pull in, clean, dedupe, update, and sync out your contacts. We automatically transcribe the business cards you collect. We have business APIs for contact enrichment. We offer Enterprise Solutions. We’re one of the best places to work in Denver, and we’re hiring. Plus, FullContact for Businesses is coming soon.
5. What . Not a master class in: Product strategy Software development methodology Competitive analysis UI/UX design theory There are many books on those subjects. I’ve only been doing this for 3.5 years. I have little to add. OTHER than to suggest that you pick a methodology that works for your engineering team. Get their buy in at the start, and try not to change things every two week.
6. This was me starting out as a PM. I had a lot of good ideas. I was confident and ready to improve the products. Much like Jon Snow on his first day at The Wall in Game of Thrones. Several days later ...
7. Like Jon Snow, I knew nothing. Startup PM is a really challenging, nebulous job. Your wear many hats. Big impact on whether the company lives or dies.
8. Instead, let’s get practical. Today, we’re going to talk tactics and best practices. Focused on being a PM at a startup. They might not work at a larger, more established company. Let’s turn you into the startup PM version of MacGyver, the guy with the solutions.
9. Practical / tactical increments. Start of a feature → launch. Two interruptions: 1. TIP: save time, money, or headache. 2. WARNING! Avoid a mistake I made.
10. Phase 1 of startup product management is learning as much as you can about: your customer your terminology your internal and external ideas your technical limitations. your roadmap.
11. You’ll hear this a lot, and it’s true. There’s really no substitute for going to talk to your customers on their home turf. We use a tool called Intercom to send segmented emails and in-app messages to local customers. We try to visit at least three per quarter, but often more than that. Visiting them on their turf allows you to see their desk, their computer setup, their mountain of business cards, their post-it notes, etc. You’ll learn a lot more. Always bring tee shirts, coffee mugs, stickers, and a gift if you can. Starbucks or Amazon gift cards are great. Make sure to end on a positive note. Share your roadmap and recruit them to be a tester.
12. There are lot of blogs on how to write better marketing emails. I won’t go into that. Here’s what has worked for me to get individual customer attention. Make it look personalized. No templates. It should look like it came from you. Don’t send it from “The Team.” Limit it to a few, short paragraphs or less. Write like a newspaper writer. The benefit to the user should be mentioned early. Make them feel like a VIP. Scarcity works. If you need to share instructions, don’t bury them. If there’s one key action you want them to take, boldface it.
13. At a startup, you don’t have help doing research on customers. You have to do all the digging yourself. And it can be frustrating. Get past what the customer WANTS. What they want is probably not that simple.
14. Pay attention to the words they use. Both writen and spoken. Pick your terminology carefully. Create a terminology guide. Stick to it.
15. In a startup, you have to move quickly. Prototype or hacky code often makes it to production. Some services don’t get the attention they deserve. Have coffee with your engineers to figure out your trouble spots. Will come in handy in planning, and in roadmapping. Some castles have dragons in them.
16. Many startup customers are often tech-savvy, early adopters. Startup employees often young people with a passion for technology. Both groups have lots of ideas. Make everyone feel like they’ve been heard. An idea forum tool like UserVoice can help you manage the flow of ideas and feedback in a quantitative way. Write timely, thoughtful responses. That will encourage more feedback. Avoid committing to timelines. They’ll remember.
17. Startup founders are like Han Solo. Never tell them the odds. In a startup, you will have lots of interaction with your founders. Founders will often come to you with an idea. Don’t tell them no or that something is not possible. Founders often aren’t linear thinkers. Show them you have a plan to get to their vision. If you have to say no, frame it as a zero sum game on the roadmap.
18. Lots of books and articles out there about how to roadmap. I’d recommend: Keep it simple. Spreadsheets or slides work. Don’t spend $ on fancy tools. Make sure it’s accessible to the company. Re-evaluate it frequently. Watch for vacations and holidays.
19. So, now that we’re smarter, how do we apply it? Due to Lean Startup, some employees think “planning” is a bad word, or evidence of Waterfall. Often, you’ll need to plan for a few weeks. Gives your team time to refactor, fix tech debt, etc.
20. Aside from a Kickoff meeting, your first step after research is to brainstorm. Lots of articles about brainstorming. Here’s what works for us: Invite a cross-functional team. Give participants time to generate ideas on their own. Seat everyone facing the whiteboard, instead of each other. Encourage a non-judgmental environment.
21. Your next step is to formalize the plan in a Spec, or PRD. As short as possible. Several pages or less. You don’t have weeks and months. No one reads longer documents. The more you write, the more you have to change along the way. MoSCoW format. Work from a template. Morph the doc into your release notes. Don’t have several docs floating around.
22. My dad is a private pilot, and he always pushed checklists. Keep a list of problem scenarios. The same ones will crop up again. Review your checklist when writing your spec.
23. At some point, it’s time to stop planning and start building. As a PM, your job is to have everything ready and organized.
24. Lots of books/articles about user stories. Here’s what works for us: Short, concise titles that explain exactly what the story is about. Use prefixes or tags to organize. No more than a few paragraphs. Use bullets for acceptance criteria. Due dates are useful.
25. Design work can be a major bottleneck. At a small startup, you may only have one designer spread across teams. Think carefully about what you need when. Not all features require mockups. For example, if you’ve already built something similar somewhere else. Or, if it’s a common design pattern. Aesthetic debates can also burn a lot of time. Get on the same page early.
26. After you’ve written stories, it’s time to organize your story backlog. Keep them lean. Otherwise, they’re hard to manage. Do not use them as an idea repository. If your tool allows: identify dependencies and due dates.
27. Avoid enterprise tools like Jira. Keep your tool simple. Pivotal Tracker or Clubhouse. Trello is almost too simple. A carefully built spreadsheet can work. Evaluate tools carefully. Expect complaints no matter what.
28. Larger companies have process to keep things moving. Statups don’t So you’ll have to. You don’t have to act like a Somali pirate. But often you’ll be required to push things along. And take on tasks that aren’t traditionally the PMs job.
29. In reality, you’ll spend a lot of your time being the project manager. That’s hard for those of us who have a creative side. As you grow and add more apps, you’ll have to do this more and more. Until you decide to hire project managers. Use a simple Gantt chart to track various tasks. Develop a simple, padded estimation scheme.
30. When you need to ship something, often you’ll put features above bugs. Make sure to fix them along the way. They’re easier to fix then. Lots of small bugs → perception of buggy product. If you build up a backlog, it gets harder to manage.
31. Since you have to spend all this time project managing and triaging bugs. How do you balance your PjM work with PM work? Avoid grooming more than 1-2x per week. Turn off devices. Lock yourself in a room. Sketch or whiteboard. Get out of the office, if you have to.
32. Now that you’ve built something, how do you test? Quickly, cheaply, and efficiently?
33. Don’t spend lots of money. Don’t get too scientific. User your local user base as a talent pool. Major problems will surface quickly. Exploratory testing is sometimes better than task based.
34. Analytics tracking is very valuable. There are a variety of tools available. GAnalytics can work. Track and analyze only key events. Use a simple naming convention for your events. Expect events to break.
35. You DON’T have a beautiful mind. Analyze only a few key metrics at a time. Make sure they’re actionable. The “collect everything” philosophy is misguided. Don’t get lost in the details. Look at your dashboards only 1-2x/week.
36. If you choose to adopt an analytics tool, watch the cost. Pay careful attention to pricing schemes. Pricing by unique users is bets. Total events can increase exponentially.
37. I’ve never shipped a feature that didn’t require us to cut scope. If you use MoSCoW format, this is easier. It’s like prepare for a negotiation. You know what your fallbacks are. Watch out product opinions masquerading as technical opinions. And vice versa. You have to keep asking “Why?” with engineers.
38. Challenging even under the best of circumstances. Sometimes, even if your stakeholders are awesome, it will feel like the Small Council on Game of Thrones. You’ll have a lot of armchair quarterbacking. The best way to avoid problems is to stay in regular communication about the status of the project. Let them know what’s going wrong. And what’s going right. Show your stakeholders that you’re moving as swiftly as possible toward the long-term vision. I’ve found that humor is often the best way to ensure they read something.