8 Keys to Getting Started
Two years ago this week, I started work as the first VP of Product Management at NTENT - a company with huge, rapidly growing market, world-famous CTO, seasoned executives and engineering team, and core technology that only a handful of companies in the world possess. Talented and friendly people, office with an ocean view, and free bagels on Fridays — all the ingredients of a great startup experience!
In a pay-it-forward kind of way, my team and I are sharing what we have learned to-date in a series of posts that hopefully will be useful to you whether you are at a startup or a larger organization.
Our goal with this series is not to focus on the function of Product Management and its importance, but rather provide some practical guidance on best practices based on our experience in building and managing products and teams that can be applied to any organization regardless of size (startup, growth, etc) and any product line (B2B or B2C). Of course, some of the tools/processes we cover and recommend may need to be modified to work for your organization/team but we believe the core principles can apply to a wide range of products and organizations. With that, the following are the areas that we will be covering over the weeks ahead:
- Getting started
- Articulating your value proposition(s)
- Defining the formula that drives your business
- Creating operational dashboards for measuring the right set of KPIs
- Finding your critical event(s)
- Developing an experimentation mindset, infrastructure and processes
- Staying focused on the user — automate continuous user feedback
- Rapid prototyping and user testing
- Ideation and innovation processes
- Effective team/org communication strategies
- Measuring and driving retention
- Key tools for a great mobile app
We hope you find these useful and maybe even occasionally fun to read. Drop us a line as a response below and let us know your thoughts and your experiences and if there are specific topics you are interested in hearing about.
And with that intro, here is the first post:
8 Keys to Getting Started
Before my first day in my new role, I did all the right things. I re-read The First 90 Days, I prepared a learning plan to review with my new boss (the CEO), sketched out some provisional objectives for my first 30/60/90 days, and got some rest to be ready for my new adventure. Everything but the “got some rest” described above ended up being pretty quickly discarded. Here is a summary of nine effective steps that did work and that I recommend when taking a new role:
- Resist the urge to make a bunch of disruptive changes right at the start. Yes, things move faster at a startup than they did when you worked at Oracle, but change is still hard and the changes you want to make on day 1 may be very different from the changes you believe are important after a few weeks of learning.
- Lean into your newness. Your lack of familiarity with the company and market is an asset, but you will lose it very quickly! Walk through the full customer/user-journey and keep notes of interactions that were painful, confusing, or not compelling. Review your advertisements, walk through the purchase experience, install and use the product, reach out for help via the support experience, read the documentation, etc. Think of yourself as the most highly-motivated focus group participant ever, and keep a log of all the rough edges to share with appropriate team members.
- Do your research. Read about the industry, competitors, customers. Work with the product. Review company documents and presentations. The faster you can climb the learning curve, the more credibility you will establish. Until people see you as credible, it will be difficult for you to have a positive impact.
- Focus on understanding how things are done and why. Frame ideas for changes in the form of a question — such as “Have we tried ____?” instead of “We should ____.” Use the term “we” even for activities that pre-date your involvement with the organization to minimize the feeling of you being a Monday-morning quarterback.
- Work hard and long. People around you should feel the (positive) impact of your presence. In the beginning, it will take you longer to get things done than it will later on — spend the additional time required to establish a reputation for delivering a high volume of quality output. Respond to emails early and late when needed — this is not the time to set boundaries.
- Establish a reputation for delivering on expectations. These are the basics of under-promising and over-delivering, but I see people mess this up all the time. This is so important, that it deserves its own post — see the following article: Stop Selling Out Your Future Self
- Build a long lasting partnership with all the functions in the organization. Product Management’s relationship with Engineering is a critical one, and one that requires attention — so continuously be enthusiastic and encouraging about the work they are doing and make sure they publicly receive the acknowledgement they deserve (for example, we make sure to mention engineers name with each internal release notification — but more on this later…). Your relationship with Sales/Business Development (especially in a start-up) is just as critical. So be charismatic and knowledgeable with customers/prospects. Be responsive to requests from Sales — and build a repository of content (internal wiki) that can be a reference for all functions as your organization scales. In addition to hopefully helping sell more of your product, interactions with Sales, prospects, and customers will help you build your intuition regarding what will make the company successful and build a world class product.
- Don’t assume that what worked well in your prior experiences will work well here. When I first started, the CEO was really focused on understanding what each member of the Engineering team was working on. Replicating something that worked well for me in a prior role, my team and I built a reporting system using Jira + some minor customization, a reporting addon, and ongoing administrative effort. While this was valuable (even necessary) in my past roles when I had hundreds of developers and dozens of product managers, it was overkill in the much smaller startup environment. We stopped using the system within a month. The lesson: what works well in a larger-scale environment may be overkill in a startup — the tools you use and the processes you follow need to fit the size of the organization.
I’m sure there were other lessons learned, but these were the main recommendations distilled from the first few weeks. We learned plenty more as things got rolling as we will share in subsequent posts.
If you have related experiences or additional suggestions, I would love to hear about them below. And if you enjoyed the post, please share it with a friend!
The opinions expressed in this post are solely my own and do not express the views or opinions of my employer.