Insights and Challenges: My First Months as a CPO in an Early Stage Startup

Photo by Josh Eckstein on Unsplash

August 2023 marked my first year at fintastic - an early stage startup revolutionizing the Financial Planning and Analysis (FP&A) space. fintastic’s first of its kind product, leverages Artificial Intelligence to advance the FP&A workflows and implements a unique user experience approach to radically ease the complexity of financial planning and analysis work.

This is my first experience as a product head for such a small, early stage company. And as with any first experience, I’ve learnt. A lot.

Despite the natural day to day preference (and need) to move on and check the box for another task, I took the time throughout the last few months to write notes to myself — thoughts, learnings and insights. Here’s a short summary of some of them (there’re more which I left for a separate summary). Hope you’ll find them useful, especially if you are starting or about to start a similar role.

The team is small, the magnitude of the role is huge.

Be prepared for it. On one hand you own the product and, to a large extent, the company strategy. Those involve market knowledge, tracking competitors and building domain knowledge. On the other hand, as (most likely) the only product person in the company, you have to deal with very detailed product specification and related decisions, especially while working with R&D team. Maintaining the big picture alongside the detailed one, requires enormous effort. The good news is that this is an acquired skill that you can improve over time.

Micro prioritization is inevitable.

Especially if your company builds a complex or extensive product like fintastic does, in which lots of effort can be invested in every piece of it — prioritizing high level flows, user stories or features involves a significant risk to spend time perfecting some pieces of your product while completely lacking others. As for startup, time is oxygen, micro prioritization is inevitable. It is essential to reach, in time, the delicate point of delivering competitive value across the product breadth vs. to reach perfection in just part of the customer needs.

Over communicate.

In large companies communication is crucial. You have to coordinate activities across, sometimes, global teams and make them work towards a shared goal. Effective communication in startups, with even very few people, is as crucial. The reason however, is different and connected to the dynamic nature of the company: relatively frequent adjustment to priorities, failures you face along the product creation period, unexpected challenges combined with high load and more. All those, make it very difficult for the team to follow the big picture and track the critical paths. This is exactly where continuous, hyper clear communication can keep the train on the railway. The right one. The product head is in many cases the right person to lead this.

Maintain critical thinking.

The velocity of the product development process in startups is high. It is magical to see how quickly a small group of talented people can add huge chunks of new capabilities to an evolving product. But…velocity can be addictive and sometimes make people prefer progress over everything else. As the product leader it is just natural that you’ll be the one who will keep questioning the decisions, your own ones included, and the solutions, make sure to maintain deep thought processes for major product decisions even if those “slow us down”.

Be prepared for the roadmap killers.

Having clients in a very early stage, while building the product, is priceless. You get feedback on existing features and requests for missing ones. They add a layer of reality to your theories. The ultimate “user testing”. But, in a B2B early stage startup environment, when you are in a race to ship a product, an endless pipe of feature requests holds the risk of killing (or at least delaying) your product readiness for commercial launch. I don’t think there’s a magical way to completely avoid this but I found the following useful:

1. Reach clarity and agreement with the management team about the company mid term goal — are you optimizing for retaining the initial clients or are you doing any effort to reach the commercial launch deadline? The former means you are feature request oriented, the latter means you should be able to push back from time to time and accept the risk of churn.
2. Dive deep into the root of the feature request, learn about it first hand and make sure to understand what is the job to be done driving the request.
3. Don’t get offended by a client asking for a feature you haven’t thought about, teaching you something you didn’t know about the domain you operate at or even thinking about a solution that is smarter than yours.
4. Remember that “no” is a valid response.

Make product decisions with no data at hand.

It is likely that if you are in an early stage startup, you have little to no data to base your decisions on. Unless you have prior domain expertise to guide some of the decisions, you’ll quickly find yourself in a situation where you need to make product decisions with no data. The following could be helpful:

1. Know the competitors’ approach — common problems sometimes share common solutions — if your competitors share a common approach to address a problem or a need, it could be a strong sign for either a practice you need to adopt or for a good area for differentiation.
2. Do not limit yourself to your industry, look for equivalent challenges in other fields and remember that although it is not our natural intuition, problems and solutions are sometimes common across B2B and B2C.
3. Try to imagine the evolution of your product given a decision you make and ask yourself if it serves as a firm enough basis for the product to evolve.
4. Document your assumptions and decisions — it helps not only to share your logic with clients but also internally with peers.

The non functional side of your product.

Product managers tend to focus on features and workflows and less on technical, non functional sides of the product. Young products are built under time pressure and tend to have a naive architecture that sometimes results in a sub optimal performance and vulnerabilities. Fixing those is complex and time consuming. This is the reason why I strongly recommend setting non-functional goals for the product from the very beginning, ideally together with the technical team who is pivotal not only in reaching those goals but also in making critical non functional measures accessible and monitored — a challenge of its own.