Over the past 24 months, we have talked to hundreds of startup CEOs, CTOs, CPOs, etc; run dozens of due diligence analyses on companies; and worked side-by-side with a bunch of founders.

As we learn from these interactions, we have also detected some common patterns. For example, there are some little details that they need to take care of early on; if they don’t, it will cost them dearly down the road.

This post will explore the points we look at early on in our interactions with product and engineering teams. We will offer some insights on why we believe these are important and some recommendations on how to take care of them from the start.

Part 1: We will discuss management related aspects and recommendations for an early stage company, from roles to processes and hiring.

Part 2: We go a bit deeper around roadmap management, key processes , goal definition and how to think about high level architectural decisions.

Part 3: It’s more around engineering best practices on building scalable and analytics friendly products from the start.

PART 1

Even if you don’t have the people and don’t like the titles, establish the roles

Companies of all sizes struggle when thinking about the key roles needed to build a new product or service. CEO, COO, CFO, CIO, CTO, CSO, CRO, etc. are all important roles at different stages of a company’s lifecycle. But when you are building a new startup, you are initially building a new product. That’s it. Therefore, in order to build the foundation of the product and the company, the roles you will need early on are Product Manager, Head of Engineering, and Growth Manager.

I usually like to explain their interactions using a restaurant as an analogy. Why? Because everybody can relate to that, no matter what your background is. Let’s dive in.

Product — The Serving Area

The product is where customers interact with your offering. It is where they sit, eat, talk, have fun, get married, celebrate their birthdays, interact with the personnel, pay, leave tips, and part ways.

The product manager oversees making sure all of that is possible, and happens in the best possible way, so customers will be satisfied using the service and paying for it. The whole experience — from the lighting and music to the way customers are received, billed, and spoken to — is the responsibility of the product manager.

Engineering — The Kitchen

Here is where the food is made. The food needs to be ready to be delivered at the right temperature, on time, and with the right presentation.

To achieve this, the kitchen staff needs to know how many customers the restaurant can seat; what items are on the menu so they can buy inventory and store it properly; what days the restaurant has more traffic than others, so extra personnel can be ready and on call; and so on.

Growth — The Management

This one may be more far-fetched but stay with me. The growth manager in the restaurant analogy will be the one deciding what kind of restaurant is the right one for the neighborhood; how much a full dinner should cost; what other restaurants they are competing against; what is most effective way to promote the place; and how to get the customer hooked.

The three roles work in concert with one another

No matter how well presented a restaurant dining room is, if the kitchen is not doing its job, customers will not be satisfied. Furthermore, neither the menu nor the kitchen will have the chance to offer and serve food that is incorrectly priced, or if they just don’t have the right clientele.

This team is the one that will dictate the future of the company and use their interdisciplinary approach to decide, in the case of a restaurant, to create a franchise or not, to build an operations manual that will allow them to repeat the successful strategies and avoid the ones that did not work.

It does not matter if the company is not big enough, or that you don’t like to wear multiple hats. Think about finding ways to fulfill the three main roles and to defend each of their interests in every decision you make.

At the beginning hire multi-functional

We have seen many startups that have tried to go one of two possible but non-ideal paths:

Startups that have no engineers or any member with engineering knowledge and hire third-party development services for extended periods

It is okay to do a proof of concept with the help of third-party developers. However, you should always aim to have a technical co-founder who can not only coordinate with the third party and make sure things are being built correctly, but also someone who is fully aligned with and committed to the vision for the company.

No matter what assurances the software factory gives you, most of their work is subject to change when your first team of developers and/or a CTO joins the company, so minimize that impact by having people from your team being part of the architectural decisions from the get-go.

Startups that want to have a team of specialists despite their product’s lack of maturity

The other end is formed by founders or companies that hire a team of specialists. They hire systems architects, front-end specialists, back-end specialists, UI experts, data scientists and ML experts…all before building the product. Unless you are building an analytics, ML-based product or building a data product with data from another source, why do you need a data scientist if there is no product yet generating data to analyze? This will only generate discomfort, attrition and burn cash with no upside.

Instead, in the beginning, try to hire flexible and resourceful engineers who can understand and identify with your vision. Look for versatile full-stack engineers, and try to make them interchangeable. As the business evolves you can focus on more specific skill sets if necessary; but try to hire subject matter experts only when you have what they need to do their jobs.

PART 2

Be pragmatic with your technology decisions

Another common mistake in early stage engineering teams is trying to follow and adopt the latest tech trend out there. These are some things to consider when choosing yours:

· Chose a technology that is mature enough so you can focus on building your product, not iterating on theirs. New frameworks often still have lots of bugs, half-built features, constant changes, and refactors that force you to constantly change and update your code to adapt. You don’t have time for that. In this phase you need to move fast and trust the underlying technology.

To assess framework maturity, look at places like GitHub (if open source) to check the stability of the different releases and participation of the community. Stay away from pre-releases, Alpha, Beta, etc. Your MVP will be plenty “Beta” enough for your team to handle.

· Make sure the technology you are choosing is well supported and widely adopted. Consider that you need to be able to find answers to your questions and a strong developer base (preferably a large organization) supporting it for a long time. You don’t want to be stuck with a deprecated framework.

Stackoverflow is a good place to assess how active the community is, how fast problems are solved, and the quality of support.

· Remember that you will need to hire talent to grow your team, many times in a specific geography. Make sure you will be able to find good developers at a reasonable price.

Stackoverflow, Angelist, and other job boards are good places to source available talent. Also, consult with the software factories offering services on that technology; ask for prices and local availability.

· Choose a tool that best suits your short and mid-term needs. Don’t choose a tool only because it is new and shiny, or because it is the most efficient (and complex), unless efficiency is key for your business.

It is very important to use the tools that your team has the most experience with at the beginning, but also try to determine if these are the best tools to allow you to move fast. You can check places like Stackshare and see what other companies are using, or which companies are using any given tool.

Don’t hate the process

Many times, we hear CEOs or CTOs answering questions about processes related to roadmap prioritization, issue resolution, deployment, bug fixing, etc. with; “we don’t need/have that yet” or “when we have a bigger team, we will address those.”

These responses betray a common misconception around processes. For sure you want to avoid over-processing or over-engineering things. Many processes are just there to micro manage, giving managers a sense of control and reporting without making anybody’s job easier. Those are processes to avoid. But other processes will make your life easier, providing guidance on how to react under certain situations and making it possible to delegate tasks among team members.

Critical processes like feature prioritization, customer support, bug fixing, pager duty, continuous integration/continuous deployment, back up, disaster recovery, etc. don’t need to be overly complicated. Plus, if you start early and think in terms of the roles involved and not necessarily the specific people, it will be easier to keep them alive and healthy over time. Implementing lightweight processes early on sets the foundation for an agile and scalable organization. If you try to wait until you have a large team for this, it will be 10x more difficult.

Make sure you REALLY understand what an MVP is

“Minimum Viable Product” is a concept so omnipresent and yet so often misinterpreted. For the sake of clarity, let’s revisit the concept.

Following Eric Ries’s book, The Lean Startup and MVP refers to “the minimum work necessary to get a customer to use a product so you can learn about a specific objective”.

We can unpack this even more with the 3 parts of the concept that should be present to make it worth it:

- Minimum: The smallest amount of work and/or money required to achieve the desired function. This includes at least rudimentary instrumentation in order to measure usage of the product.

- Viable: capable of working or functioning adequately, and also have a reasonable chance of succeeding. It has to meet the basic needs of the person using it.

• Product: IT HAS TO BE A PRODUCT!!! It may not match what you envision in your wildest dreams but it needs to solve something for a customer: a need, a wish, something that will give them satisfaction.

Don’t re-invent the wheel

An important aspect of the work we do with startups is analyzing the product roadmap. While doing this we often encounter one of the following items:

· “Build advanced analytics and dashboarding tools.”

· “Iterate within our internal sprint management software.”

· “Model our A/B Framework.”

· “Create ticket management platform.”

All of these things, as important as they are, most likely are not core to your product offering, so don’t waste your development resources on them. Most of the companies that offer these services have generous startup plans that will help you to get off the ground and start operating. Think “buy” rather than “build.”

This doesn’t mean that you should completely forget about the total cost of ownership. As generous as they may be, some have pricing models that will not be a good fit for you and your business model. Do a little math and ask, “What if I get 10x users (or traffic or transactions)?” and “What if I get 100x?” and see if it still makes sense. This also applies to finding open source versions of Tool A or B and running it by yourself (or, worst case, forking an open source project). Remember, you will need to host and manage this service. Most of the time, you’ll conclude that it’s better to plug into someone else’s SaaS instead of building your own.

Make sure to establish common goals

You can make use of OKRs, WIG, or whatever framework you prefer, but make sure your goals and objectives are clear, easy to communicate, simple to track and control, and can be identifiable or relatable for all teams in the company.

Without these, you will see that teams do not always push in the same direction, different areas seem to contradict each other, which can cause a disconnect between priorities and roadmap items.

All goals and objectives need to emanate from your company goals, and every employee’s objectives or goals should be easily tracked back to one of your core objectives.

Make sure you keep these up to date when circumstances change — be they discoveries or market changes. As you update them, make sure you make the reasons for changing them public in order to get everyone on board.

PART 3

Remember Authentication is not the same as identity management.

A lot of us confuse authentication — making sure a user has the right keys to enter — with identity management — identifying unique users, where they came from, and their preferences and relationships.

I have seen many startups that adopt either Facebook or Google Login to get the token, and then they stop there without actively tracking and trying to understand who these users are.

External logins can help you start fast but will make profiling difficult down the road. If you use these tools, make sure you ask for the right permissions so you get the data you need about your customers. Then you can deploy tools to understand who they are and how to reach them.

Every action a user executes on your service should be traceable to a single, unique user profile in your data repository. This includes not only the transactional data on your back end, but all user interactions throughout your platform: clicks, conversions, push notifications, outbound emails, support tickets, etc.

Don’t silo your data

Most entrepreneurs are probably excited by now with all the possibilities data gathering offers, but sadly it is not that simple.

As we mentioned before, in this new digital world data is being generated at all levels by many different subsystems: identity, API performance, attribution, navigation flows, app analytics, click-through rates, social circles, etc.

All of these things happen in relation to one another in the real world, but in the digital one the different systems are gathering and storing the data on their own closed repositories. Why separate them if your goal is analyzing them? Well, most of these tools want to lock in customers by locking in the data and provide their own dashboards and recommendations.

In most cases that is not a good thing. The benefit of correlating all of this is that it will help you understand why things happen and how to influence those things. Look for tools or solutions that will allow you to export and integrate data from multiple sources in different ways.

Focus on building customer-level event streams because they are the basis for learning the full story. Beyond mere demographic and aggregated data, customer level data will help you most when trying to understand and replicate — or avoid — certain user behaviors. Centralize, correlate your data, and follow the stream.

Think about data gathering from the start

Your customer interacts with your product in a wide variety of ways:

· They find out about the existence of your site/app.

· They navigate there in some way

· They do things in the product

· They receive and interact with emails, SMS or push notifications

· They experience crashes or issues with the service

· They contact support

· …and they generate your key actions

All of these interactions generate valuable data. Make sure all of it is being logged and properly tied to a customer. This will help you understand your customers better and meet their needs proactively.

Imagine the following scenarios:

· A customer is reaching out to your customer service for the third time in regard to a malfunction in your app. You see the tickets, but don’t really understand the root cause. After a while, when you finally figure out what happened and try to reach out to the customer to explain that everything is solved, the customer has already churned. What do you think could have been done better? Imagine all the opportunities you had to provide a better service. Now let’s work on a better scenario:

o When the customer creates their account, you can attribute the customer to a particular campaign or channel, so you have some profile information on the customer, and know how much you paid to acquire the customer

o Your customer generates a lot of data by their frequent use of the service and is flagged in the system as a valued customer. You can see how much value they have generated so far, and what is their potential

o You are using an APM tool (like NewRelic) or a bug management tool (like Sentry). All of these tools are generating data related to performance or crashes and tying them to a single customer ID

o When the customer reaches out to your customer support the system checks its latest transactions and issues. So instead of wasting precious time trying to figure out what happened, ask if they are calling about the last “incident” they had and let them know that you have already created a ticket about it, and that you will contact them when you have a resolution

o As soon as the problem is resolved or understood, you update the status of the ticket, which generates an automatic message to the customer with an explanation and a free discount coupon for their troubles

o The system adds the customer to a specific cohort of customers that had issues and received such treatment to see how much more or less loyal they are in comparison with other customers that experienced similar issues but never contacted customer support

o All of this will allow you to understand if all that effort is paid back in terms of LTV, NPS, virality etc. so you can either scale it down or try to automate the whole thing, so users don’t need to contact the call center at all

· You are thinking of building a mobile web version of your app, since you had some feedback that your native app is a bit big (in size) and you are getting a lot of uninstalls in some markets.

o Your apps are properly instrumented so you track every single interaction of your customer with your app adding a lot of metadata in the process. This metadata includes phone model, OS version, screen size etc.

o You also track network availability. Are your customers using your service mainly on wifi or mobile networks?

o Your push notification tool lets you know who of your customers might have uninstalled your app

o Your growth accounting analysis shows a lot of resurrected users complete a couple of transactions and then churn again for a while until some of them resurrect again

o With all of these you come up with the following conclusions:

1) In some emerging markets, your app size is an issue. Most devices are low-end Android with low storage, and users prefer pictures to your app. But as they still enjoy it, they download it occasionally. On top of that, you realize that your current native app is not optimized for small screen devices

2) Most of the usage is on wifi, which means that customers are probably prepaid, and use their data carefully

3) Your app doesn’t work at all when there is no data connection, even though some information there is not fully dependent of data being available

4) The best scenario would be an Android-focused PWA app with a small footprint. It would have some offline functionality available and data sense capability, to get more data intensive information when on Wifi

Most of these analyses would not be possible without a rich data gathering focus and proper identity management in place.

Beware of dependency layer

It is not uncommon for highly data-focused teams to start having big issues with engineering once they start to scale. Their desire for more analyses, more prediction, and more real time recommendations is hurting the transactional capabilities of the system. If you have ever heard that, it means that your analytical layer is tightly coupled to the transactional layer, which is really bad.

Work early on to separate layers, to create reading replicas or Read DBs replicated in real time, so you avoid killing performance when doing some heavy data extraction. What’s more, you can even separate RFI (request for information) transactions from RFC (request for change) operations so you can grow and easily scale the aspects of your architecture that are suffering.

Don’t overload your app with third party stuff (if possible)

Wait what?? Didn’t I just say that we need to gather as much data as possible?? And that we should use what is already out there?? So how come you are telling me to not overload my app?

It is true that most of these data gathering tools require instrumentation of your app. They all provide some nice SDKs that are the only way to gather data into their platforms (apparently). This leads to some unfortunate downsides:

· Your app gets heavier and heavier. Sometimes I have seen apps that have more third-party code than their own.

· Each SDK sends a copy of all events to their cloud: not very efficient for the users that want to save data and might even make your app slower.

· Every time an SDK changes, you need to run and update your app (re-submit to the marketplace).

· If you change an event, or add new ones, you need to update multiple SDKs and make sure you did it right.

Fortunately, there are tools that take care of these issues allowing you to instrument the app one time and then use that to send the data to a single location (or proxy) that will make sure it is replicated to all of the different services you would like to use. This takes care of many of the problems we mentioned before since now:

· App size is minimized since you only need to include one SDK and instrument it following best practices. Chances are you will be able to use that for most of the solutions out there.

· All events go to a centralized location and from there are distributed to multiple end points.

· If an endpoint changes, you don’t have to worry, in most cases the vendor will take care of that in the cloud, not in your app.

· If you change an event or flow, you only update it once.

· And as a bonus, you can create a local copy of all the events from all sources on your own repository, so you solve the information silo problem we discussed above.

There are several options here like Segment, M-Particle […] etc. Just be careful because their price (your cost) will grow with your customers. If that is an issue, you can always fork the open source project of Segment and do all the heavy lifting yourself ?.

Make data easily available internally

I remember a long time ago in my past corporate life, access to data was restricted to a very select group of people. It was a privilege that needed to be earned and had layers…many layers.

How do you expect to get your team aligned? How will you trust they are making the best use of their time? Or building the right things? If you don’t trust someone on your team with the data needed to understand your business, they should not be part of your team in the first place.

It’s in the early stage when you build your core team, your values, your culture. All of that should be built on trust.

If you share your data, your insights and your knowledge, your team will be able to better focus and allocate their time, and why not, maybe even challenge some of those insights.

To build a data driven culture, everybody needs to be data driven. In other words, eat your own dog food.

A data-driven company should not make decisions by pure intuition. Always try to use data, explain how you read it and what conclusions you reached.

If you have a meeting to discuss a change to the product, start by explaining your hypothesis, what data could be used to test it and why. Lead by example; if you don’t follow these rules, and just shoot in any direction the wind blows, your team will either try to do the same or stop listening to you.

If you don’t use the data, you will spend your whole time searching for silver bullets instead of using all the lead ones you have lying around.

This post was longer than I anticipated and whether you got here after reading through it or just skipped to the end, the key take away would be: a) think about the boring stuff (process, roles, common objectives, simple architecture) early on, when you have a small team and a simple product because if left unchecked these will become bad culture, wrong hires and technical debt. b)test and challenge your assumption and hypothesis before dedicating precious resources (time and money) to them. c) To achieve #2, cherish the data your product is generating, make sure you store it, label it and are capable to relate it to customer, actions etc.