My takeaway from Early-stage startups
Key learnings when you build for early-stage startups
Note: This article is intended towards broader decision-makers and not for Product managers (PMs) alone!
Oh no! Not again! Not another change in requirement! Why don’t we ever finalize things before we close high-level requirements??? Why didn’t I take a formal mail sign-off?
This was one of my most frequently uttered lines when I was working with startups, over the last 4 years, across FinTech in India as a product professional. And I am not an isolated individual here!
Startups are hard, made challenging due to the tangential focus on agility and rapidly evolving priorities. And to top it off, throw in expectations around innovation and creativity. All with very minimal processes in place or adequate resources to undertake some activities.
And you realize why startups are one of the best breeding grounds for product managers (PMs).
Startups are easy, no one ever said. But wait till you are a part of early-stage entities! More so, if the company is trying to find a footing in the market. Or is trying to do something different. And early-stage startups have the additional challenges of limited clarity, too much of parallelism and minimal focus on closure. This coupled with 10x the challenges faced in a normal startup makes it a mammoth challenge for most individuals.
This is not to say that early-stage startups don’t release successful products. Technically, every major ex-startups like Amazon, Uber, Airbnb, etc. all started out as early-stage entities till they hit their sweet spot. The key thing most of these companies focused on early was building the right thing and the right way (not talking about KPIs and metrics here).
Here, I try to list down some challenges faced by startups from a product standpoint.
Parallelism: a key ingredient of most startups ‘ challenges is that they pursue too many things simultaneously due to the low success rate of certain initiatives, including certain moonshots. This can create a lot of friction in the system, not to mention, confusion and impacts productivity.
Ideation to Execution: As startups, multiple threads are commonly pursued. But when teams put in a lot of focus on lofty ideas, realistic and good ideas get ignored. Most PMs end up frustrated with lack of progress, impacting productivity and triggering exits and causing heartburn.
Excessive planning: As a PM, thinking of roadmaps matters. But it won’t add much value when your product isn’t ready or has been accepted by the market yet. Excessive planning ends up derailing items that matter and will bring in a positive impact as well.
Technophilia: A lot of startups believe they ‘need’ awesome tech (valuations?), irrespective of their core offering. This puts a lot of pressure on PMs to build features that hardly add value, something that can be handled offline or manually.
Every problem has solutions. Here, I recommend a few probable ones from a product building standpoint.
Razor-focus: Focus is not unique advice for startups, but it matters a lot more for early-stage as what you (don’t) build matters a lot! Are your new programs pending sign-off by legal or lacks last-mile details? Do not push to product queue. This serves two purposes: helps identify bottlenecks in the process and identify if the process/product is even going mainstream, both of which ensure a higher success rate and greater business impact.
Execution-bias: Execution is always the supreme king. But more so in a startup, because of agility that a startup has over its competitors. PMs need to given clear mandates to build and detail products to the micron. This in no way means that PMs need to be focusing on only 1 feature or module, but rather helps the PMs prioritize their tasks and move quickly. This ensures two things: greater agility in release and continuous improvement.
Micro-planning: Product strategy is a buzzword on a lot of profiles! But startups need to live by the day. PMs love planning for 30–60–90 days and this indeed matters in a mature organization. In startups, PMs need to focus on 5–10–15, building and iterating faster. This also helps PMs re-orient their approach and focus in case of changing business priorities. This helps in two things: lesser rework and constant feedback.
Crowd-source: Startups have a lot to build and do. This ensures the PM is constantly loaded with operational tasks. This results in loss of external focus, something critical, to be provided by business teams but is missed out due to them being neck-deep in work as well. PMs need to constantly venture out to meet stakeholders (table-stakes!) as well as actively involve other teams in the entire process.
Hustling-mentality: Hustling is an abused word, and it is indeed to a good extent. Startups need to hustle, not just to get things done but get it done faster with hygiene quality. Setup basic processes, manage data on excel, use manual mailers, write quick and clear requirements, etc. Hustle to ensure you can get things rolling with minimal effort till you are clear. This has two benefits: process/product innovation and fairly well-rounded features.
Dollar-value: Most startups have frugal budgets, even ones who have funding. A good way to discourage excessive building is attributing a dollar value to each release/project. This is value, not cost alone! Approximate revenues reasonably and deduct costs (salaries and opportunity). This facilitates two key things: the dollar impact of building and the dollar saving by not building.
A lot of the above recommendations look idealistic and well beyond what most PMs might be able to accomplish on their own. And indeed, its partly true as not all early PMs are hired at senior levels and in some cases, founder/s double down as a PM. This is where the initial leadership team, especially Founders, step in to make the product building process smoother and much more successful. Founders, due to the skin-in-the-game naturally have vested interest in building the right product!
The above approach is suggested, largely because good Founders know their products VERY well and the leadership team is actively involved in going out into the market to sell the ideas. This, in turn, brings rich user feedback as well as allows faster iteration of the initial features before a full-blown release. PMs will need to be empowered to work closely with externally-focused employees to build better products, rather than pushed to work with engineering.
While working with engineering is a key responsibility, it is key to note that this initial coordination should not be too bureaucratic, thus negating the concept of excessive collaboration, as outlined above. It makes great sense to onboard engineer folks from startups and similar or related domains so that engineering can focus on building basic tech without a PM. And the PM can focus on building useful features rather than obsess about integrations or run an MNC-style sprint plan (retrospective, review, etc.)
That said a BIG point of caution: there is a tipping point for everything. You can circumvent the process or hustle up to a point. You can’t work in a chaotic environment forever!
An equally important point to note: the list of challenges is indicative and the extent of it can vary by industry, geography and even companies. Founders need to assess their standing realistically before taking the plunge into making changes in the organization. Undoing changes or constantly changing processes can be very painful and detrimental to the startup, from a business standpoint, and for the morale of the employees.
As organizations begin to mature and have a lot more clarity and focus, most of the above challenges vanish. And new ones crop up! That is a story for another day!
