Startup PM: Getting your Product out of the door by getting everyone to focus
Being a startup PM is no easy feat; Everyone has an opinion about everything related to your work and you are late to ship before you even got started. It’s important to get everyone you are working with to stay focused.
Ironically, in a startup, everyone can be a lot of people. These people would be spread across teams from business development to customer success, leadership, engineering, design etc. and would need you to engage all gears managing upwards, horizontally, downwards and outwards.
Get your Product Strategy Right
A good place to start is coming up with your product strategy. It’s such an important piece to have at any given time that nearly all conversations between you (the PM) and leadership would be centred on. It must capture the vision, goals and initiatives to achieve your product goals. Once agreed upon, your product strategy becomes the one thing that you base all product decisions on; making it easy to determine if a feature should be built by simply stacking it up against the product goals. All the energy spent by your teams in engineering and design has to at least move a needle in the initiatives in your product strategy.
Coming up with your product strategy depends a lot on the stage at which your startup is at. If it’s in the very early stage you could be working with ideas from your CEO and other people in leadership that might not be strongly backed by data. It’s up to you to go on and validate them. Other times you would need to charter the course by yourself towards a certain pointed direction. In later stage startups that have been operational for a while, they would have some data on the subject and the direction you are being pointed towards will not necessarily be based on a hunch. Occasionally, a business strategy would already be in place. It’s important to align your product strategy to the direction the startup wants to take. Your product strategy informs your product roadmap and you must get buy-in from the relevant stakeholders before you proceed.
Define your Product Roadmap and share it
Once your product strategy is in place, use it to produce a product roadmap. Your roadmap captures the initiatives defined earlier in your product strategy on a timeline. Depending on the scope of the problem, resources available to you and whether you have any deadlines, your roadmap could span from one quarter to a whole year. Time is always a limited resource and you could request additional resources or manage the scope with thoughtful prioritisation on the go-to-market such that more significant milestones are scheduled to be closed earlier.
I have seen a lot of value in producing two roadmaps; a tentative but strongly informed annual roadmap that focuses mostly on the key milestones per quarter without going too deep into the details and another quarterly roadmap for the current quarter that takes a deep dive into what’s happening every week covering features and timelines for them that informs anyone whether I am on schedule or not, what the team is currently working on, what’s been done and what’s still pending at a glance. I share both of these roadmaps with product and engineering teams and the tentative annual roadmap with business development and customer engagement teams.
It’s easy to go straight into features and forego the product strategy. This would be a recipe for failure as you would not have a vision and end goals in mind which leave room for everyone to question why certain features are going to be built before others. With a product strategy, you can easily take the focus away from features and realign everyone outcomes.
Share any changes you make to the roadmaps to the teams. Besides, I also share talking points on how to talk about the product and features we have built or are building every quarter to all teams especially business development to guide them on what kind of promises they can make to their prospects. If you have not shared an elaborate roadmap, your business development team will come to you with product feature ideas that they think should be built very urgently to help them close a new lead they have been chasing. It’s hard to say no to these requests if you have not shared a product roadmap with them. This could only make things worse if you give in and end up having to remove an essential item from the roadmap which could have cascading effects all the way up to the product strategy. Introducing changes abruptly on the roadmap and making them urgent out of the blue also exerts immense pressure leading to burn-out on your engineering teams. Sharing your roadmaps with your customer engagement team will also know how to manage customer expectations if they know about what’s coming in the roadmap.
Iteratively Work on your Product Requirement Documents (PRDs)
PRDs translate the roadmap into detailed documentation that guides the output of design and engineering work. PRDs describe the purpose, goals, release criteria and timelines for any given feature. It’s important to involve your engineering and design teams as you work on your quarterly product roadmap. They will bear the brunt of the development work and will be instrumental in giving more accurate time estimations based on the experience of the team. Set up sessions to brainstorm the features, scope and make time estimations with them. What comes out of these sessions will highly inform what you end up putting on your Product Requirement Documents (PRDs) for the various features.
Well done PRDs will save you a lot of back and forth with design and engineering teams. However, PRDs are the opposite of agile. They take quite some time to write elaborately and can very easily be blockers. Write your PRDs iteratively focusing on what’s MVP and immediately required to press go on a feature and share so that teams are not waiting. Continuously update your PRDs as development continues to describe features as they evolve at various versions.
Execute
There are different approaches to execution and choosing the right approach is not the easiest thing. In general, the industry is guided by Agile, Lean Startup and Design Thinking.
At its core, Agile values responding to change over following a plan. Many things can change in the course of building your product including market conditions, moves made by your competition or further down it could occur to you had underestimated the complexity of your problem. Agile roots for short working cycles at the end of which you pause to reflect on accomplishments, learnings, new insights and next steps.
Eric Ries in the Lean Startup argues that every project you undertake is an experiment that seeks to answer the question “Should we build it”, instead of “Can we build it” And if the answer is yes, “Can we build a sustainable business model around it?”. Lean Startup roots for a cadence of experimentation and iteration that only warrants further investment if each experiment yields evidence that more work should be undertaken on the project.
On the other hand, Design Thinking teaches teams to take an empathetic look at the customers they are building products for to understand the core needs being addressed. Then come up with a set of technically feasible solutions that meet those needs and are viable for the business through a series of facilitated brainstorming sessions.
It’s difficult to settle on any one of these philosophies but whatever approach you choose to go with will end up aligning with one or more of them. You can use a mix of these depending on which team you are working with; I find myself using Agile for engineering teams, design thinking for design teams and lean startup for product and leadership teams. Regardless of what philosophies you would be following with a team, you should make sure that you check in regularly with your teams while still allowing ample time for progress between check-ins. Agree with each of your teams on the frequency of your check-ins. The agreed frequency is highly dependent on the experience of your team and should be short enough that you can catch and rescue situations early enough and yet long enough that your team doesn’t feel micromanaged.
I would love to hear your thoughts on how you go about working with teams to build new products. Connect with me on Twitter @athmangude.
