Uncovering betters way to manage products in a startup by doing and helping others do.
After spending 5 years in the exciting world of startups, I realized that there is a specific product mindset that thrives in that world. That mindset, if carried over to established organizations or large corporates, can have some devastating effect on the Product manager. However, in short sprints, this mindset is great to get off the plateau and rise higher.
As a startup grows, the role of the product manager (or the product team) evolves. Where they were initially driving macro gains through a dogged focus on low-hanging-high-value items, they now drive more strategic optimizations that tie-in with the overall product strategy. Their initial dogma revolves around independent decision-making, learning things about the team, the customer, and the product. As time progresses and the Product-Market Fit is achieved, the backlog changes to a more strategy-driven one.
The Startup Product Managers’ Manifesto
But before that, a product manager in a startup should abide by the following:
There are a few tenets that drive these items:
- Every member of the development team is working together — egos have no place.
- Business focus is paramount here. Do whatever it takes to make the business successful, even if it means the customer experience is sacrificed in the short term.
- The team is independent to do what is right for the business. Trust in the team. The term ‘independence’ is bound to be misinterpreted here. The team takes the right decisions — the product manager only facilitates the conversation and conveys them across the board.
- Removing hurdles, immediately, in the way of success (or potential success) is required
- Agile practices, can and will be disregarded to achieve business success. The debt that it incurs will be handled in the later stages
- Processes will be formed, broken, and formed again. There is no process that above change/improvement.
- Time is a valuable resource — the longer you take to decide on a strategy, the lower the team’s enthusiasm will be…
- Everyone is guilty, until proven innocent.
Let’s look at each item one by one with examples.
Humility Over Ego
Keep your ego aside. The ability to say ‘I don’t know’ is critical to the success of the product function. You have to know when to bullshit and when to admit defeat. Note that saying ‘I don’t know’ doesn’t mean you give up! It only means that right now, as of that moment, you’re not in a position to answer. The ‘I don’t know’ has to be followed by ‘but I’ll find out by X date/in X hours’.
Ego is the biggest creator of bad products. Once egos come into the picture, you would have lost a part of the team and the faith of the stakeholders. You have to be humble — your successes are those of the team, your failures are your own.
With humility, you learn — so adopt a method of learning through failure.
Remember, no one asked you to show up — you are there on your own time making sure there is alignment. A complete loss of a product function will not stop the organization from functioning the same way the loss of engineering teams (or even some key engineering team members) would. You are a proxy function, and your opinions are just that — an opinion, amongst a thousand others. Build that humility and adopt a servant-leadership style.
Product over politics
In the early stages of a startup, there is bound to be some level of politics. Founders usually bring their trusted people to the decision-making committee. Hence, there will be some level of toe-stepping, hurt egos, and the subsequent group formation. Each team overriding each other priority that can cause massive roadblocks in product delivery.
We deal with that by advertising, in plain and simple language, that the product is above all things politics. The founders/leaders need to know and trust the team to make the right decisions for the product and partake in guiding them/providing them with information to those decisions.
Similarly, inter-development team politics should be identified and rooted out.
Personal agendas and individuals glory take a back-seat. Highlight members suspect of this and clearly outline how these things are not driving the product goals.
Example
A close relative of the CEO was the Content manager and hence, every problem he faced with the content was immediately prioritized — at the cost of revenue-delivering features. As a team, we went up to the CEO and informed him of the damage this had done to the product and the opportunity cost incurred. Within days of having this conversation, the CEO wisely decided that prioritization shouldn’t fall onto an individual. It had to be a collective effort.
As we were learning things at the time, we decided to publicize our product & sprint backlog to demonstrate which items were a priority — fostering a cross-functional conversation and leading to better decisions.
Working Iteration over perfection
A working product is better than a perfect product. Usually, both the technology and design teams fall victim to perfection. The myopic view is derived as a function of improper communication.
In the startup product role, we value a working product, that performs the goals it has been assigned, without the need to find perfection. This can mean forgoing A/B tests to identify the best-possible iteration OR spending extra time to avoid technical debt.
The tradeoff between technical debt (which can be both design & code) and the working product is a no-brainer. Incurring technical debt is a trade-off and should not be avoided. The debt, however, should be present in the backlog — to be taken up for a later time.
Example
A designer wanted to provide a cool (honestly, a beautiful looking) interaction. This would, however, take up 3–4 days. During this time, we could have completed a few other critical, revenue delivering features. We settled for simpler interactions.
The designers’ need for perfection wasn’t unwarranted. Even you, as a product manager, would want to deliver exceptional value — whether it is experiential or functional. However, in the biggest context, those pieces do not fit as easily as other items on the backlog.
Delivery & Ownership Over Discussion & Process
In an unknown land, it is easy to spend days discussing the best way forward. People will site their previous experiences and offer ways to navigate. These discussions stall and delay the value delivery pipeline.
What helps in this phase of startup product management is the understanding of the following:
- The team is responsible for the outcome. There has to be a sense of ownership — a pride that together the team has delivered the outcome — good or bad.
- Failure won’t be chastised — it should be a learning going forward.
- Moving is more important than stalling
As the saying goes, ‘nothing ventured, nothing gained’.
Example
When working on the delivery of a particular feature, a small portion of the team figured that the approach taken would fundamentally slow down the site and cause huge experience issues. When it was highlighted to me, I asked for alternative approaches. The mini-team came up with a plan that made sense. After a few questions detailing the specifics, I quickly wrote a small draft of the new approach. I shared this with the CTO and CEO and asked if this smaller team could take the approach. After a short meeting, it turned out that this approach had value and could be explored.
Today, this approach powers the entire platform and is often touted as one of the stellar pieces of technology for that startup. But for that, the team and I had to put our names on the line and take ownership of the delivery. We worked overtime to deliver this, outside of our current duties and it worked!
A side-effect of that was that this mini-team became revered in the dept — something I am very proud of to date. Their success meant I could get buy-ins from the development team faster.
Actuals Over Possible
This ties in with the above two items. We prefer established routes over possible good-to-explore routes. This can mean blatantly copying of competitor approaches or even going by the collectively decided approach.
Practically, this means we focus on reducing options in our approaches and focus on the actual value delivered. We focus on directly impacted metrics, leaving the speculative in-direct metrics to fend for itself.
Example
When we were redesigning our website, we wanted to see if we could optimize the buying journey, along with some technology overhauls we were doing. The UX/UI team wanted to go in the direction of exploring user tests and the data. However, this would have eaten up into the time we had to redesign and launch.
As the business needs were to quickly optimize and launch the new site, I insisted that we blatantly copy the core framework from an overseas competitor and optimize once we were live. It would have taken at least 4–5 weeks to understand the right consumer behavior and that would have had massive opportunity costs. By simply mirroring an overseas competitor we were able to complete the redesign and deliver the core technology optimization to the customers and improve the business metrics.
Keep in mind, these discussions are to be had with diplomacy — you do not want to come across as someone who doesn’t value the role played by UI/UX. Painting the bigger picture and the organization’s focus, and citing opportunities for improvement in the future will go a long way in ensuring collaboration.
Breaking Barriers Over Living in the Comfort Zone
This applies both to the product manager and the team involved. For a product manager, it’s about getting their hands dirty — the data team is busy with work on something? Get access and build your reports. QA team is taking time to clear off some test cases? Do it yourself!
Similarly, for the team — standard conventions cannot get in the way of the business goals. “We used to do it this way in my previous organization” is a phrase we’ve to discourage. Every norm has to be vetted before the team collectively agrees on it.
Example
I build my dashboards and reporting mechanisms. I do not wait for someone to generate the reports for me. If the team uses a different tool than what I’m used to — I learn that tool. No work is beyond me or beneath me.
Capacity Pushing Over Capacity Planning
Startups usually do not have a lot of resources but have a tremendous amount of work to be done. The excuse that we do not have enough people to launch a feature within a given time should not be entertained. Find ways to get things done and achieve them together. Capacity has to be pushed before we can start the capacity planning. The reason I added this as a part of the Startup product management is that teams have this need to assign items to the future. I.E. Knowing that 3 new devs will join, they’ll push those items till those devs join. We’ve to fight this attitude and stoke a constant fire in the team.
Conclusion
Startup product managers are in a unique position to mold the product to their liking. The key aspect of the product function is prioritization. But if you cannot build your own priorities, how can you prioritize work for others?
I’ve found that being disciplined is crucial to success. Some of the great product folks I know lead a very disciplined life. While you may be starting out, set the foundation right now for a better tomorrow! Hopefully, the manifesto I’ve outlined will help you create those priorities, and lead a more disciplined product work-life!