DEV Community: Vadim

Measuring an engineering impact. Pyramid of needs for product engineers.

Vadim — Thu, 22 Aug 2024 14:10:53 +0000

Last time, we discussed how the role of a software engineer has evolved into the role of a product engineer and what the fundamental differences between them are. Today, I'd like to delve into the work routine and understand the key principles of operating as a product engineer.

Since the emphasis in this new role is on rapid iterations to gather feedback and validate your solution, it means we need specific tools to assess the code you release. When I talk about validation, I'm not referring to technical metrics, but rather how your solution impacts the overall business. Let's call it end-to-end (e2e) validation, encompassing the following points:

Impact on fundamental technical metrics such as database load, server resource consumption, and browser memory usage.
Impact on integration technical metrics, including the number of non-200 responses to users, increased response times for specific API endpoints, and a "laggy" interface.
Influence on local product metrics, such as the number of users who started using a feature after an improvement (adoption level) or the number of users who consistently use it.
Impact on business indicators - measured in the money generated by users utilizing the features you've worked on.

If we take another look at the points mentioned above, we'll find a common thread that unites them all - to measure impact, we need to "stay informed" about what's happening with the system in various dimensions. In the world of product development, there's a specific term for this - observability.

Observability in the context of software development refers to the system or application's ability to be easily observed and analyzed. This involves collecting data about the application's operation, its state, and performance to ensure transparency and the ability to quickly detect and address issues.

The list of previous points can be represented as an onion, where each ring is within the responsibility zone of different teams.

Level One: Engineering Metrics. Owners - Software Engineers.
Level Two: Integration Metrics. Owners - Site Reliability Engineers (SRE).
Level Three: Feature Metrics. Owners - Product Managers.
Level Four: Business Metrics. Owners - Analytics Team.

Each level has its key metrics, and each team is responsible for its level in the onion, providing a comprehensive assessment of the impact on the product and business.

For most modern companies, evaluating based on 1-2 of these points is quite commonplace. The more advanced ones try to assess changes against three. However, only A-players thoroughly assess all four parameters. Why is that? Because carrying out a detailed evaluation demands substantial effort, advanced skills in multiple areas, and smooth cooperation across various team departments. For very young startups, implementing such processes would be prohibitively costly, while the advantages would be minimal.

In the early stages of product development, the basic shortcomings are usually clear, and all the low-hanging fruits are visible. However, as your solution matures and it's time to enhance or discover new growth areas, such a system becomes a primary tool in your arsenal if you don't want to move blindly forward.

Returning to engineering…

All of this, of course, depends on how teams are organized within the company, but let's get back closer to our daily work routine. When working on a task, you're still writing code, there are no changes there. However, with such an approach, you need to think a bit further than just how to write code; you should also be interested in how your code works in production and, most importantly, how your code impacts the product.

I like to envision this as a pyramid, something like Maslow's hierarchy but with an engineering twist. Each level becomes a concern only after we've managed to fill the previous one, and for success at each level, we'll need specific tools that best address the needs.

So, we've written the code, initiated the deployment process, and now it's time to observe

Is my code working? 🛠️

Difficulty: Easy 🟢 
Owner: Developer 👨‍💻
Tools: Bugtracker 🐛
Evaluation time: up to 1 hour ⏲️

The bottommost level. Before evaluating further, you must ensure that your code fundamentally works. The primary metric is a binary answer: yes if your code somehow accomplishes its task, or no if it fails 100% of the time, even for the simplest user story without corner cases.

Typically, simple bug trackers like Sentry or Bugsnag are used as tools. Evaluation time is usually less than an hour. Depending on the release process, validation can occur at various stages—some use QA department testing, others rely on team tests, and some may test independently directly on sandbox/production environments. These days there's nothing new about this, and hopefully, we all do it.

Is my code working well? ✅

Difficulty: Medium 🟡
Owner: Developer, but you'll need initial setup of integrations with 
tools typically falling on DevOps/SRE shoulders ⚙️
Tools: Log management systems, times-series databases 📉
Evaluation time: 10 minutes to 6 hours. ⌚

After ensuring basic functionality, the next step is to assess how reliably our code is working and give it a quantitative evaluation. The primary metric here is the error/success rate.
Tools for this can include logging systems like the ELK stack or Grafana, or more time-series-oriented tools such as Prometheus, Datadog, or AWS CloudWatch if you operate under high load. To assess this parameter, you need to ensure that your code logs information or sends metrics to the relevant system. Configuring dashboards to have a visual representation is also crucial.

What's the ideal metric values to move to the next level? It all depends on the situation! For example, a billing system for processing orders on your site should strive for a success rate approaching 100%, while tasks related to unvalidated image classification or the use of an unreliable 3rd-party API may have a lower reliability level.

Sometimes evaluation can be challenging, especially if you need to introduce a new feature to users and teach them how to use it. In such cases, you can manually test the main user scenario with different inputs and settings 5-10 times.

Additionally, at this stage, automated alerts become your good friends. They send notifications if this metric starts deteriorating over time, allowing you to proactively respond to changes before your users become dissatisfied with the product

How does my code impact the system as a whole? 🌐

Difficulty: Medium 🟡
Owner: DevOps or developer 🧑‍💻
Tools: Log management systems, times-series databases 📊 
Evaluation time: 10 minutes to 6 hours ⏳

There are numerous technical metrics reflecting the health of your service. Depending on the product, their criticality may vary, but your changes can easily lead to spikes in any of them. For example, using a database query in a loop without attention can significantly increase the number of database queries, loading an entire file into memory can spike server memory consumption, or synchronously calling a 3rd-party API that responds slowly can increase the average HTTP response time for your users.

Most modern hosting or cloud providers cover these metrics out of the box. Many services, such as databases or queuing systems, also default to supporting data transmission to monitoring systems like Prometheus or OpenTelemetry. You need to put in some effort to start working with these, but the good news is that you only need to do it once for each tool.

Evaluation time: In the best-case scenario, you can identify the issue immediately. More often, problems arise with an influx of traffic, so detailed logging becomes your best friend in investigation to quickly understand what exactly is leading to deteriorating metrics. Ideally, this can be caught during performance testing, but maintaining load testing for every change, especially in the development of new products, can be a challenging task.

For example, in Monite, we use a set of multiple tools that support developers in collaboration with the DevOps team. For monitoring hardware metrics, such as database load, we use metrics exported to Prometheus. For a more detailed analysis of microservice performance, we have deep integration with Sentry. And for exploring end-to-end performance, we implement distributed tracing.

How does my code impact the success of a business feature? 📈

Difficulty: Hard 🟠
Owner: Product Manager, Analyst 📈
Tools: Google Analytics, Amplitude, Data Warehouse 🔍
Evaluation time: A few days for designing the A/B test, and from
a few weeks to several months for data accumulation and drawing 
conclusions 📅

Once we've ensured that technical metrics are alright, we can move to the next level - assessing the impact of your changes at a local product level. Analytical tools such as Google Analytics or Amplitude can be helpful here.

Let's consider a simple example - the checkout form on your service requires users to input their country in a strict format. Data show that the conversion to the next step is at 40%, and the simplest hypothesis is that users don't understand the expected input format, leading them to close the page after the first unsuccessful attempt. You decide to weaken the validation, and the conversion increases to 50%. However, you feel it's not enough, so you add autocomplete to the form, further increasing the conversion to 80%. This is the product impact of your changes.

It might not sound too difficult, but when trying to implement this in practice, many questions arise. What if I have a multi-platform application? How do I measure the impact of each change on a feature when we release them simultaneously? How can we understand that it's your changes affecting metrics and not external factors? Most of these questions can be answered with one solution - A/B testing. Conducting clean A/B tests requires analytical skills and, more importantly, a significant volume of traffic to draw statistically significant conclusions. The latter is a major hurdle for small companies.

Another reason I categorized this as “hard” is because such evaluation requires designing, bootstrapping, and implementing metrics for each feature of your product. As compensation, proudly use the "data-driven" badge on your resume.

How does my code impact the success of the product? 🚀

Difficulty: Insane 🔴
Owner: Product Manager, Analyst, Finance 🧑‍💼
Tools: Data warehouses, reporting tools, BI tools 💾
Evaluation time: from 1 month 🗓️

If in the previous point you are examining how users behave when interacting with your feature, transitioning here shifts your focus from the feature to the user. Who is the user? What problem does your product solve for them? Where did they come from? What keeps them from leaving for competitors? You literally need to know everything about them. This requires significant investments in a data collection, analysis culture and data infrastructure.

From an analytical standpoint, the complexity lies in establishing the correlation between key business metrics and local product metrics. You need to learn how changes, like increasing the form conversion rate by X%, will impact key business metrics (such as ARR, LTV, Churn rate, and any other metrics vital to your business). From a product standpoint, you need to understand not only your current users but also those contemplating using your product.

Honestly, this goes beyond the direct responsibilities of an engineer, but I believe that if you consider yourself a product engineer, you should at least be curious about how effective the solutions you release are and how they influence the successes and failures of the business as a whole.

How does your company measure the impact of engineering decisions on the product?

The Evolution of the Software Engineer Role into Product Engineer

Vadim — Wed, 28 Feb 2024 13:44:51 +0000

Over the past 10-20 years, software development approaches have undergone significant changes. What used to resemble the Wild West has now evolved into a vast ecosystem built from startups, accelerators, and venture funds. This transformation has inevitably influenced how companies structure their internal processes. Due to intense competition, the primary question for young companies has shifted from "how to build" to "what exactly to build." This has prioritized speed over high quality, emphasizing the velocity of hypothesis validation, market responsiveness, and adaptation to changes.

We observe how lean and scrum methodologies have displaced the waterfall model, focusing on addressing bottlenecks that are crucial in the new realities. However, are there other ways to optimize the process?

Typical team structure

Most modern development teams can be broadly categorized into two types:

Conservative Teams: These teams typically consist of a few engineers led by an engineering team lead. The focus is on a more traditional hierarchy, where the team lead guides the technical aspects and decision-making.

Cross-Functional Teams: These teams are more contemporary and are composed of a cross-functional mix. They include a product manager and a designer who are responsible for customer communication. The team is still led by an engineering team lead, and there are multiple developers working on tasks.

The choice between these models often depends on the nature of the project, the organizational culture, and the specific goals of the development effort.

However, both of these approaches share a common drawback - all feedback from a large number of stakeholders goes through the Product Manager. The feedback is somewhat processed by the Product Manager, then passed on to the team or team lead. Specifications are written, requirements are decomposed, and the task is handed over to the developer... except for the details and business context. The developer works with a task that's already prepared and doesn't directly interact with the client. If they have questions, they ask the Product Owner or team lead, and either the questions are passed on or the team lead attempts to solve them based on their own knowledge. All of this resembles an attempt to play a game of Chinese whispers.

At the end of the sprint, developers submit their task, roll it out to production, and it turns out they did something completely different. The entire process has to be initiated again. What's wrong with this approach? Each link in the team becomes a bottleneck for task progress. Due to limited capacity of team members, answering questions and passing context can take days or even weeks, significantly increasing the feedback loop for your new product features.

Is there a way to optimize this process? Certainly - by eliminating unnecessary links in the existing chain. That's how the role of a software engineer evolved into a product engineer.

Who is this product engineer of yours?

Product engineers possess a powerful combination of skills. They excel in communication, building strong relationships internally with colleagues and externally with customers. These strategic thinkers go beyond just completing tasks; they see their work as a key force driving towards a successful IPO. The most vital aspect is that product engineers deliver. They conceive, construct, and meticulously validate their work, ensuring that new features quickly reach customers.

To illustrate how the feedback process changes with the new approach, you can refer to the following diagram

So let's consider the features of a product engineer's work and how they differ from a software engineer:

Measure of success:

Software Engineer: Success criteria often revolve around the quality of the engineering system they develop.
Product Engineer: Focuses on solving user problems. Success is not always about the most productive code or code covering the most corner cases. It's about writing code that best addresses user problems, closes the most popular use cases, and provides the maximum possible UX for end users.

Scope of work:

Software Engineer: Works based on ready specifications and tasks (for example in JIRA).
Product Engineer: Concentrates on a user problem, usually described in the form of a user story.

Depth specialization:

Software Engineer: Often has a clear specialization in frontend or backend development. For software engineers focused on technical excellence, having a specialization and deep technical expertise is vital.
For a product engineer, it's crucial to balance speed and quality. They are often specialists without a strongly defined specialization in frontend or backend. They can contribute to any part of the product or are full-stack developers, following a T-shape or even W-shape approach.

Customer interaction:

Software Engineer: Main sources of requirements and feedback are product owners or their immediate supervisors.
Product Engineer: Emphasizes communication with users, involving both quantitative feedback through analytical systems and qualitative feedback through participation in customer development interviews to better understand user needs.

Development and delivery speed:

Software Engineer: Can afford to solve technical problems that do not always directly impact end users.
Product Engineer: Typically contributes to product development and drives shorter iterations, focused on obtaining feedback quickly from end users for their solutions.

What are the requirements for the role and how to become successful?

So, you've decided that you like this and want to try yourself in such a role. Should you just go and tell your boss about it? You can certainly try, but it doesn't always work. Transitioning to such a format usually requires changes in the overall company structure and internal processes, and not everyone is ready for such rearrangements. For larger companies with a strict and deep vertical structure, such a transition may prove more challenging than for horizontal companies or startups that are more aligned with them.

If we look at the job market, a similar correlation is evident. For example, in a LinkedIn job search, where larger companies post vacancies, a search for software engineer yields 143,146 job listings, while product engineer results in 1,773, which is only 1.2% of the total number of job listings. However, if we examine platforms where engineers are hired by younger companies, such as www.workatastartup.com, the distribution becomes much more interesting — 665 companies for product engineer compared to 686 for software engineer indicating a high demand for such specialists in young and growing companies.

Since this role involves continuous learning across adjacent tracks, the company culture should be geared towards growth and open communication among employees with different skill sets. If you are already an established technical professional, you will need to enhance your understanding in areas like product management, UX design, and analytics to identify issues in your product and propose user-effective solutions.

The next point may be a bit controversial, but I believe that to transition into the realm of product engineers, you should already be a software engineer with at least a middle+ or senior level. To address user problems, a developer must already have a well-developed technological worldview and experience to understand the pros and cons of specific solutions and make necessary trade-offs. The primary challenge in such a position should be product validation of the chosen solution, rather than writing the corresponding code.

By the way, when we talk about UX, we don't always mean the interface. It is more about how the user interacts with your product. For example, being an API-first company at Monite, 99.9% of user interactions with our product occur through the API. Therefore, we address this at the API level by adhering to industry standards, providing detailed documentation, and creating walk-through examples formatted in Postman that cover most user scenarios.

Does this bring value to the company?

Embracing a no-compromise approach, product engineering focuses on efficiently reducing communication noise. Forming small, agile teams leads to fewer meetings, rapid decision-making, and a streamlined feedback loop. By eliminating unnecessary layers of communication, product quality experiences a significant boost. When engineers have a comprehensive understanding and the authority to make decisions, the process becomes faster and more effective, preventing delays or errors.

When I discuss this topic with employers unfamiliar with such an approach, there's often a certain level of skepticism for two main reasons:

Developers have gained a reputation as technical geeks interested only in manipulating bits, optimizing algorithms, and scaling containers.
The approach where an employee is expected to be involved in more than one direction is often perceived as a lack of focus and a stress-inducing factor related to work.

Finally, I have a source to reference to refute these claims. In the DevOps report by Google released in 2023, there is a separate chapter dedicated to how a focus on users affects various team parameters. Among the findings, I would like to emphasize:

Teams with a strong user focus experience a 40% higher organizational performance.
Prioritizing user needs leads to a 20% higher job satisfaction.
User-focused approaches significantly improve other metrics.

Wrapping-up

Fundamental changes in the industry always impact the requirements for companies, which, in turn, influence approaches to development and the internal organization of teams. So, if, in addition to development, you are interested in:

Growing along a non-technical track
Gaining a better understanding of the domain you work in and the existing problems within it
More closely aligning your efforts with the successes or failures of the company

Then perhaps now is the perfect time to be at the forefront of these changes and consider embracing a new role for yourself.

If you prefer not to participate in this and feel more comfortable in the technical track, it doesn't mean you'll be left behind! Since all your teams are now focused on users and often do not pay full attention to engineering, there is a need for individuals who will address this aspect of your workflow. Therefore, roles such as architect or platform team (which I will revisit in future topics), providing a strong technological foundation for product engineers and preventing them from diverging too much, become even more crucial than before!

In my blog, I still focus on approaches to work, team building in the early stages of company development, the role of a product engineer, and establishing a data-driven culture within a company. If these topics interest you, feel free to subscribe for me and other Monite developers.

Engineering Challenges in B2B and B2C Startups

Vadim — Wed, 22 Nov 2023 09:07:53 +0000

The internet is filled with articles comparing work cultures across different company types, especially in marketing or product management. But what about software developers? Do these differences impact them too? Absolutely! Understanding the nuances between B2B (Business-to-Business) and B2C (Business-to-Consumer) can be a game-changer. Each sector has its own unique set of characteristics, demands, and obstacles that significantly shape the work of software engineers.

Before diving in, let's set the stage. I'll use "B2C" to describe products that engage directly with end-users. This includes not only consumer-focused applications but also B2B products with a low average ARPU, where the primary revenue stream comes from the self-serve customers segment. These are platforms like Miro and Zapier, catering to a broad range of users who can onboard independently.

On the other hand, our B2B segment refers to enterprise-focused products. Such companies typically work with a smaller number of clients but with more substantial contracts, often in the tens of thousands, or hundreds of thousands of dollars.

Throughout my career, I primarily worked in B2C companies, occasionally advising teams involved in B2B. However, after joining Monite, I experienced the stark difference firsthand.

Alright, let’s go step by step through the main differences, analyze where they come from, and explore the opportunities they open up for your professional growth.

In-depth specialization vs. broad accessibility

In the B2B corner, you’re the tech wizard – called upon to solve specific challenges for major players. Corporate clients rely on you to provide robust solutions, sparing them the complexities of handling those issues themselves.

Sounds exciting, right? But here’s the thing: you always need to be at the top of your game. Your business must meet the high standards set by your clients. If you’re dealing with financial data and payments, get ready to navigate intricate regulations across the countries they operate in. Managing credit card data? Compliance with PCI-DSS is non-negotiable. And when working with medical data, you’ll become well-acquainted with HIPAA. And that’s just the beginning…

In the B2C space, your customers turn to your product for convenience or entertainment. They’re not looking for complex problem-solving; they want a user-friendly solution. While the B2C entry barrier is low, making it a popular choice, it's much like a bustling local cafe – lively but packed. While the vibe seems welcoming, brace yourself for fierce competition. Many are jostling for the spotlight in this vibrant arena.

Stability and fault tolerance

When a big client invests in your product with the expectation of saving their development team’s time and offloading certain tasks, any weaknesses on your part within their IT ecosystem can lead to a swift termination of your partnership. This applies not only to technical glitches, errors, and system failures but also to products that don't effectively meet their designated objectives.

Each failure also impacts your client's reputation with their end-users, as it directly compromises the quality of service they provide. This, in turn, can negatively influence your standing within the industry.

It’s also crucial to consider acquisition costs. Acquiring clients in the B2B sector is a resource-intensive and time-consuming task, demanding a personalized approach. So, when you lose a client, it's not just a hit to your wallet; it's hours of hard work down the drain and a chunk of your revenue gone.

On the flip side, the B2C world is a bit more forgiving of minor glitches or even partial downtime. Here, clients usually use your product for straightforward tasks. Even if there's a small issue or a short downtime, it's not the end of the world. Why? Because the average sale is probably between $100–200, and you're catering to a much larger crowd. This time partial failure or temporary degradation of one of its functions has a less severe impact on your entire user base.

But here's the thing: to really grow in the B2C space, you need a massive user base. And while there's a steady flow of users coming in and out, this model can handle a bit of client turnover.

All of this means one thing: B2B products can't afford mistakes. That's why there's so much emphasis on making them fault-tolerant and thoroughly tested, way more than B2C products. As a result, variations emerge in the development processes. When working on a B2B product, you encounter extended release cycles, stricter Quality Assurance procedures, and daily encounters with terms like release management and zero bug policy.

How working with customer feedback differs

In the B2B world, you're often working with a client base that's in the tens or hundreds. This smaller number means you can get to know each client personally. Your products in this space are typically designed to weave seamlessly into a client's existing infrastructure, which means the integration process can get pretty detailed. It's not uncommon to find yourself giving technical advice to engineers from your top-tier clients, and sometimes, you might even grab a drink together.

Within a B2B-focused company, you'll probably have several support tiers, each handling different levels of complexity. There might also be a specialized integration team. Their job? To offer deep technical support, help with integrating products, and sometimes even tweak the product to fit a particular client's needs.

Switch over to the B2C side, and things look a bit different. With potentially thousands or millions of users, it's tough to have a personal connection with each one. Most of the feedback you'll get will be in the form of data: numbers, charts, and graphs in your analytics dashboard. Sure, every now and then, you might chat with a super-user or an influencer. But mostly, conversations about your user base shift from talking about individual users to discussing broader groups or segments.

Because of this, B2C companies have a big appetite for product analytics. They need robust data engineering to gather, process, and make sense of heaps of data. This isn't just a numbers game; it's about making informed decisions based on a deep understanding of customer profiles and being able to measure how effective those decisions are.

Why rapid adaptation is important

In the enterprise B2B space, it's common to see long-term contracts. The cost of integrating these solutions? Sky-high, especially when you compare it to B2C, where businesses often lean on subscription models or even offer their services for free. Given this landscape, it's crucial to keep a close watch on what your competitors are up to and stay in tune with market shifts. This is especially true if you're in a young industry where competition is fierce, and you don't want to miss out on attracting new clients.

When it comes to product development in such an environment, the emphasis is on quick, short cycles aimed at fast delivery. You're probably not spending a ton of time drafting detailed tech documentation or plotting out product development for more than a few months in advance.

To keep up this speed and swiftly test out different business ideas, many turn to agile approaches like Scrum. It's all about iterative feature development, and when exploring new product avenues, the MVP (Minimum Viable Product) strategy is often the go-to.

Step growth vs. gradual growth

In the B2B space, the journey from customer interest to full integration can be a long one. This extended timeline often gives you a buffer to gear up for any unique demands a new client might bring. You can rally more developer manpower and fine-tune your infrastructure to cater to each new client's needs.

On the flip side, when you're in the B2C game, a big focus is on how quickly a user can jump in and start using your product. With such a low barrier to entry, you might see spikes in user activity out of the blue. Maybe you rolled out a catchy ad that's gone viral, got a shoutout as the "product of the day" on Product Hunt, or perhaps it's just that time of the year when everyone's looking for what you offer. Suddenly, your user count could skyrocket. This unpredictability means you've got to build your system to be super flexible. It should be ready to scale up in a snap and adapt on the fly to whatever comes its way.

Security

Beyond just meeting regulatory standards, it's crucial to sync up with your customers on security protocols. Today, a data breach can spell disaster for businesses big and small. However, big enterprise clients tend to put cybersecurity under the microscope before they even think about signing a contract or integrating your solution. They might ask you to secure certifications like ISO 27001, set up robust internal security guidelines, limit who can access production data, or even put your system through rigorous penetration tests.

On the other hand, small to medium-sized businesses (SMBs) aren't usually as stringent about these security deep dives. Addressing basic concerns, like preventing SQL injections, often ticks the box for them. And if you're a budding company, you might find that tasks like updating software to patch vulnerabilities get pushed down the priority list, making way for more immediate business-driven goals.

Brand visibility and recognition

Even though you're diving deep into complex challenges and working under tough conditions, your hard work might fly under the radar for those outside your field.

Your product often powers the big players from the shadows, without the general public getting a firsthand look. Contrast this with developing B2C tools or solutions for widespread SMB use. In those scenarios, explaining your latest project to friends and family is a breeze.

Plus, there's the added perk of getting personal recognition for that cool new feature you helped bring to life.

Overall thoughts (or a conclusion of sorts)

Launching a successful B2C company is no walk in the park. It demands a harmonious effort across every facet of the product.
Here's a breakdown:

User acquisition: Draw in the "right" users without breaking the bank.
Strategic planning: Choose the best paths forward for growth.
Backlog prioritization: Ensure you're always showing impressive month-over-month growth.
User support: Keep existing users happy and engaged.
Engineering: Never lose sight of the technical side of your product.

Given the fierce competition in the B2C space, this all comes with a hefty dose of uncertainty. This unpredictability can make venture capitalists wary of investing. If your leadership team isn't packed with industry bigwigs, securing substantial early-stage investment can be an uphill battle. With funds spread thin, it's tough to give every aspect of product development the attention it deserves.

At this juncture, zeroing in on a product-market fit is paramount. B2C startups are more prone to shifts in direction compared to their B2B counterparts, which usually have a clearer picture of their target audience and the problems they're addressing.

Budget constraints and the potential for sudden shifts in direction mean it's often unwise to pour too much into engineering. You'll likely be working with a tight budget, focusing only on the essentials to roll out the next product version swiftly for another round of testing. This environment is ripe for tales of quick adaptation, problem-solving on the fly, and product building.

However, B2B startups present a different picture:

They often have a clearer idea of client pain points.
Initial customer acquisition can be smoother, thanks to founders' connections or direct sales efforts.
The uncertainty is generally less, but the depth of knowledge required about the domain and product is greater.

So, if you're aiming to be a specialist in a niche area and prefer a more stable work environment (though priorities might still shift), B2B startups could be your calling.

Whether you're venturing into B2C or B2B, both paths come with their unique challenges and rewards. It's all about finding the right fit for your skills, passion, and the kind of challenges you're eager to tackle.

In my blog, I mostly focus on approaches to work, team building in the early stages of company development, the role of a product engineer, and establishing a data-driven culture within a company. If these topics interest you, feel free to subscribe for me and other Monite developers.