And this is where prioritization comes in. In this article, you'll learn how product managers prioritize work, what guides their decisions, and the frameworks they use to decide what does and does not get built.

Table of Contents

• Why Prioritization is Difficult

• What Do Product Managers Really Prioritize?

  • User Problems and Not Feature Ideas

  • Business Outcomes, not Tasks

  • Trade-offs, not Preferences

• What Inputs Drive Product Prioritization?

  • User Feedback and Research

  • Product Metrics

  • Business Goals

  • Technical Limits and Demands

• Prioritization Frameworks

• Why Do Prioritization Frameworks Exist?

  • RICE Scoring

  • Kano Model

  • MoSCoW Method

  • ICE Framework

  • Impact vs Effort Matrix

• How to Choose the Right Framework

• Common Prioritization Mistakes

• Conclusion

Why Prioritization is Difficult

Prioritization can be difficult because product managers must almost always choose between multiple viable options. Between requests centered on optimization and bug fixing, increasing revenue, and reliability concerns from users, stakeholders, the design team, engineers, and sales departments, we can see how easy it is to build the wrong thing.

Each of the requests would be entirely legitimate when considered separately, but determining which is more crucial at any given moment can be challenging. Prioritization decisions are frequently made based on incomplete information, such as not knowing which features users will actually adopt, whether a request represents a real problem or just a loud minority, or whether it will significantly improve a metric. which, in contrast to engineering tasks, are simple: is the bug there or not? Does the code work or not?

The fact that the trade-offs are not immediately apparent is another factor making prioritization challenging. Other worthwhile projects are postponed or abandoned when a product manager gives priority to one. Although these lost chances don't immediately result in failures, their effects can mount up over time and affect long-term results, growth, and product quality.

What Do Product Managers Really Prioritize?

A common misconception is that product managers only prioritize features. PMs don’t just choose between whether to ‘add dark mode’ or ‘add in-app messaging’, they also choose between reducing churn and improving retention. Therefore, what PMs are really prioritizing are:

User Problems and Not Feature Ideas

At face value, user feedback consists of solutions and not problems, like:

• Add dark mode

• I want to be able to edit a typo after posting on my story

• Can you make it possible to export this as a PDF?

A PM won’t just take these requests as they are but will ask why, how, and what.

• What pain point is the user experiencing?

• How many users are experiencing this?

• Why does the user want this?

After asking these questions, the PM doesn’t just prioritize being adding the dark mode feature but rather, evaluates that users requested for that feature because, apart from personal preference, they struggle to use the product for long periods especially at night and that dark mode is one possible solution and there may be others

Business Outcomes, not Tasks

We can look at it this way: a task is something the team does and an outcome is the result the business wants. Some examples of tasks are:

• Fixing bugs

• Redesigning the onboarding process

• Adding dark mode

Increasing activation rate is one example of an outcome. Product managers prioritize outcomes because they are measurable, connect work to business goals, and tasks alone do not guarantee impact. So, when deciding what to prioritize, a PM considers whether it will increase engagement, improve retention, or reduce churn.

Trade-offs, not Preferences

This is where things get complicated because, as a product manager, you occasionally have to make trade-offs between things like speed and quality, features and time, resources and scope, quality and cost, technical debt and new features, and so forth.

What this means is that PMs don’t make preference-based decisions when they have to prioritize, but rather, their decisions are constraint-based. This implies that instead of saying, “I prefer this idea,” they are saying, “If we do this now, we can’t do that.”

What Inputs Drive Product Prioritization?

Before anything is prioritized, PMs gather input from multiple sources like:

User Feedback and Research

These include interviews, usability tests, user reviews, social media comments, direct feature requests, quantitative data from product analytics, and metrics like Net Promoter Score (NPS) or customer satisfaction (CSAT) scores, which offer a human-centered approach that relies heavily on customer needs, behaviors, and pain points.

Product Metrics

Metrics like activation rate, churn, feature adoption, retention, session duration, Daily Active Users (DAU) and Monthly Active Users (MAU), session frequency, and so on, help PMs understand if and where the product is underperforming.

Business Goals

Prioritization has to align with the company’s strategy and vision because every product exists to serve a business objective, and those objectives directly influence what a product manager prioritizes at any point in time. Business objectives have a big impact on product priorities. While a revenue-focused company might invest in monetization features, a growth-oriented company might prioritize onboarding and acquisition. Product managers frequently give core user experience enhancements and dependability top priority when retention is the aim. Because of these changing objectives, prioritization is dynamic and changes as the company does. So, it depends on whether the business is focused on growth, retention, cost optimization, or revenue.

Technical Limits and Demands

Simply put, even if an idea is great, it may not be possible at the moment because, even if they sound simple, they may be quite complex to implement. For example, a product that supports offline mode. Also, many features depend on another being completed. Lastly, there is technical debt, which basically refers to shortcuts taken that make a system hard to change in the future. An example includes poor documentation or design. Technical debt, amongst other things, increases bugs and slows down development.

Prioritization Frameworks

Prioritization frameworks are structured approaches that product managers use to make explainable and rational decisions. They are decision aids that help PMs compare options. Prioritization frameworks eliminate guesswork from decision-making in product management, thereby helping the product manager make informed guesses instead of instinctive ones.

Let us have a look at some of these frameworks, why they exist, why and when to use them.

Why Do Prioritization Frameworks Exist?

Prioritization frameworks are like aids, not formulas that help a product manager make defensible choices. These frameworks exist to enable PMs make informed decisions, and they do that by asking ‘who?’ and ‘how?’.

• Who does this help?

• How does it help?

• How is it going to be built?

• How does it benefit/align with the company vision?

So no, frameworks do not replace judgement, they only support it. Therefore, instead of making decisions based on whether they think something will be a good idea, PMs they ask the hows and the whats. Some prioritization frameworks in product management include:

RICE Scoring

Developed by Sean McBride at Intercom, RICE stands for the four elements—reach, impact, confidence, and effort—that are taken into consideration when developing a product idea. This framework provides an answer to the question of how much value will be produced relative to the effort by comparing each element.

• Reach: Measures how many users will be affected by the product in a given time period. It is about scale and must always include a timeframe, otherwise the numbers become useless. For example, 5000 users monthly or 35% of weekly active users.

  A small improvement for many users can outweigh a large improvement for very few users. This is evident when comparing the reach of two features, like Feature A, which affects 20,000 users monthly, and Feature B, which affects 500 users monthly. It is evident that even though the improvement is small, its reach surpasses that of the big improvement, therefore making it more significant.

• Impact: Measures how those customers will be affected by the product. Unlike reach which is about scale, impact is about depth or value. Sean McBride suggests estimating the impact on an individual person. Like, “How much will this project increase the conversion rate when a customer encounters it?” And points out that this can be replaced with other goals, such as “increase adoption” or “maximize delight”. Seeing as impact can be difficult to measure, a scale of 0.25 to 3 is used, where 0.25 is minimal, 0.5 is low, 1 is medium, 2 is high and 3 is massive impact.

• Confidence: This measures the level of confidence in executing ideas and is gotten from sources like user feedback and A/B testing and uses a 100% scale, where 50% is ‘low confidence’, 80% is ‘medium confidence’ and 100% is ‘high confidence’. This accounts for uncertainty and risk, and it helps to answer the question, “How sure are we about this idea?” and prevents speculative ideas from ranking too highly.

• Effort: Refers to the time it will take the team to execute an idea. Effort is like the investment, and the other elements, reach, confidence and impact, are potential benefits. Effort is usually measured in person-months or person-weeks and puts things like engineering time and design work into consideration. This is the most important element in this framework because two ideas with similar value may differ greatly in effort, and a lower effort increases the RICE score.

The RICE formula is:

RICE Score = (Reach × Impact × Confidence) ÷ Effort

While the RICE scoring method of prioritization is excellent for data-driven teams, it can be too long and difficult to understand.

Kano Model

This categorizes features based on customer needs and how they affect user satisfaction and was developed by Noraki Kano in 1984. It has three parts, namely:

• Basic needs: Features that customers expect your product to have, like core reliability and login functionality. Sometimes, users don’t notice them when they exist but when they don’t exist, it leads to dissatisfaction.

• Performance needs: Features where better performance increases satisfaction. This means that this features scale satisfaction linearly, that is the better they perform, the happier users are. An example is faster load time.

• Delighters: Unexpected features that create excitement. These are unexpected features that make users feel heard and happy like TikTok allowing users post images in comment sections.

One of the cons of the kano model is that delighters eventually become basic expectations.

MoSCoW Method

This framework was developed by Dai Clegg while working at Oracle in 1994 and it categorizes work into:

• Must have: Essential for the release and can either make, or mar the product.

• Should have: Important but not critical. That is, the success of the product is not dependent on it.

• Could have: Nice to have but not important.

• Won’t have: These are not relevant to the product.

This framework is very easy to use and understand, and that is one of its biggest advantages and it is particularly useful for release planning, MVP definition, and scope control. But the disadvantage is that without proper categorization, every feature can start to look like a must have and categorizing features as a ‘won’t have’ can also prove difficult.

ICE Framework

The ICE framework is a lighter-weight alternative to RICE, commonly used when data is limited or speed matters more than precision.

ICE evaluates initiatives based on:

• Impact: How strongly the initiative is expected to move a key metric.

• Confidence: How certain the team is about the expected impact.

• Ease: How easy the initiative is to implement relative to others.

Each dimension is typically scored from 1–10 with the total average being the ICE score.

ICE works well when:

• Products are early-stage

• Teams need quick prioritization

• Detailed effort estimates are unavailable

A disadvantage of this framework is that it sacrifices accuracy for speed and it can give biased results.

Impact vs Effort Matrix

This is also known as the value vs effect or value vs effort matrix and is one of the best suited for visual team discussions and quick alignment with stakeholders.

Initiatives are plotted on a 2×2 grid that is based on the value it will yield (impact) and what it will take to achieve it (effort):

• High impact/Low effort → They are top priority and also known as big wins.

• High impact/High effort → The features that fall into this quadrant are high yielding features but must be planned carefully, hence, the high effort.

• Low impact/Low effort → Features that fall here are known as fill-ins. They are optional or nice to have. They require low effort and yield low impact and should only be worked on when high priority tasks are complete.

• Low impact/High effort → Low impact and high value? Nobody wants their team to waste time on such features so they should be avoided at all costs.

The elements that make up this framework are much like that of MoSCoW which contributes to its simplicity. It is also intuitive and can serve as a more flexible and visual substitute for RICE. A disadvantage is that it can be subjective and both impact and effort are estimates.

Other frameworks include:

• Weighted Scoring Model: Prioritizes ideas by scoring them across multiple criteria, such as user impact, strategic alignment, effort, risk, and key metrics, with each criterion weighted according to its importance to the business.

• Opportunity Scoring: Identifies aspects of the product that are of importance to the users but are not being satisfied. The formula for opportunity scoring is: Importance + (Importance – Satisfaction) = Opportunity

• Desirability, Feasibility and Viability Framework: Evaluates ideas based on desirability, feasibility and viability. That is whether users want them, if the team can build them, and finally, if the business can sustain them.

• Cost of Delay: This measures the financial impact of postponing a task and is an excellent framework when dealing with time-sensitive products.

• Product Tree: Is a visual method that replaces the roots, trunk, branches and leaves with systems, current set of features (core functionality), features/enhancements, and new ideas respectively. This helps teams explore ideas and visualize growth in a structured way.

How to Choose the Right Framework

No prioritization framework works in every situation, so choosing the right one depends on the team’s goal at that point in time. Factors that affect how to choose the right framework include:

• The product stage has significant impacts on framework selection. Early-stage products frequently lack accurate data, therefore a lightweight framework such as Desirability-Feasibility-Viability will be more effective for rapid learning. Growth-stage products often have enough users and analytics to provide structured comparisons, making RICE, Weighted Scoring, and Impact vs Effort more useful. Finally, mature goods prioritize optimization, revenue, and risk, where timing is critical. Frameworks such as the Cost of Delay help to assess added value and urgency.

• Data availability is also an important factor because frameworks presuppose varying degrees of confidence. Using data-driven frameworks without accurate data can result in false precision. When metrics and past performance are available, scoring frameworks become more useful. When they are not, simpler qualitative models are more reliable and honest.

• Stakeholder and team requirements also have to be considered because frameworks are useful for communication as well. They aid persuading stakeholders' decisions, collaboration between teams like design and research is facilitated by user-centered frameworks like the Kano model. Also, teams and stakeholders can rapidly align with frameworks such as the product tree.

• Adaptation over rigid use basically means that frameworks should be modified, instead of using them in a rigid manner. They should be used as guidelines for thinking not a direct path to certainty. That being said, frameworks are often adjusted, simplified, or combined to fit the product stage, available data, and team context.

Common Prioritization Mistakes

Prioritization can still go wrong even with excellent frameworks and data. Such mistakes are common, but they can have a big impact on long-term results, team trust, and product quality. Some of these mistakes include:

• Prioritizing the loudest speaker is a common mistake in product prioritization which happens more than you’d think. Some stakeholders or team members, for example, speak loudly and frequently that they unintentionally dominate the roadmap even when their ideas or requests don’t align with the user interests or company goals. It is necessary to distinguish between the person making the request and its actual value in order to prioritize tasks effectively.

• Confusing urgency with importance is another very common mistake in prioritization because sometimes, everything looks like a must have, but not everything that looks urgent is important. Urgent tasks come with deadlines or short-term pressure—for example, an upcoming demo presentation—but important tasks yield long-term value like reducing technical debt.

• Relying on instinct alone and not fact will most likely not get you the desired results as a product manager. If you make a decision just because it feels like a good idea, without validating it through research or grounding it in a prioritization framework, the effort required to fix the resulting mistakes can be significant, often costing more time, resources, and trust.

Conclusion

Finding the ideal framework or making error-free choices are not the goals of prioritization. It is about making conscious trade-offs with limited time, data, and resources—and being able to explain why those trade-offs were necessary. Prioritization frameworks are used as tools to eliminate bias, reveal assumptions, and encourage better decision-making in the face of uncertainty rather than as rigid rules.
Finally, because effective prioritization is a constant process, priorities must be revisited often, assumptions must be validated early, and decisions must be documented.

As products evolve, user needs change, and company goals shift, priorities must be examined and adjusted. Product managers who constantly prioritize clarity, proof, and intent are considerably more likely to create solutions that add genuine value for both users and businesses.

I have seen too many founders who are smart, legit, and ambitious get ghosted by investors simply because they couldn't walk through their unit economics.

It's not personal. It's math.

So here it is: Numbers that will either carry your pitch or quietly kill it, explained by someone who has sat through them time and time again, with examples, and no fluff.

Here’s what we’ll cover:

• 1. Burn Rate: How Fast Are You Lighting Your Cash on Fire?

• 2. Cash Runway: How Long Before You Run Out of Cash?

• 3. CAC (Customer Acquisition Cost): How Much Does it Cost to Convince Someone to Pay You?

• 4. Customer Lifetime Value (LTV): How Much is One Customer Worth Over Time?

• 5. Gross Profit Margin: What Do You Actually Keep After Delivering Your Service or Product?

• 6. Monthly / Annual Recurring Revenue (MRR / ARR)

• 7. Churn Rate: How Fast Are Your Users Leaving

• 8. Payback Period: How Long Before You Recover Your CAC?

• 9. Earnings Before Interest, Taxes, Depreciation, and Amortization (EBITDA)

• 10. Valuation: What’s Your Company Worth – and What Supports that Number?

• Real Talk Before You Close That Tab

  • Real Experience

  • Why This Matters

• Conclusion and Final Thoughts

1. Burn Rate: How Fast Are You Lighting Your Cash on Fire?

Burn rate is the speed at which a startup is spending its cash. Basically, how fast are you consuming your venture capital to cover over overhead until you generate positive cash flow from operations? It’s a measure of negative cash flow.

If you’re spending $80K a month to keep the lights on (payroll, AWS, your workspace snacks, and so on), that’s how much cash you’re burning each month. But many startups calculate two different burn rates: gross burn (how much cash you’re spending, ignoring any revenue), and net burn (monthly operating experiences minus any cash you take in each month). Net burn basically measures how fast your cash is shrinking, and it’s often what investors care more about.

Real talk: investors want to know when the plane runs out of fuel before they board. Thats what this metric helps them understand – how fast you’re going through the money you have.

At some point, if a company has a high burn rate, it has to reduce structural costs by cutting expenditures on labor, rent, marketing, and/or capital equipment. The burn rate is an important metric for any company, but it's particularly important for startups that aren't yet generating revenue. It tells managers and investors how fast the company is spending its capital

Watch this video to understand more about Burn Rate.

2. Cash Runway: How Long Before You Run Out of Cash?

Cash runway tells how long a startup can continue to operate at a certain burn rate until they are out of cash. For startups without revenue, you can calculate this by dividing available cash by total monthly expenses. Available cash is defined as the funds that are accessible now or can be accessed at a later time relatively quickly to pay for expenses.

When you’re making this calculation, it’s important to not include any anticipated fundraising and other uncertain sources of capital.

Actively managing cash runway is crucial for startup survival and growth. With a significant percentage of startups failing due to cash shortages, founders need to closely monitor their cash burn rate and runway.

The length of runway needed varies based on factors including the startup’s stage, industry, and milestones. In tighter venture capital markets, startups should plan for longer runways and consider strategies such as increasing revenue, reducing expenses, or raising additional capital. Regularly updating financial models and understanding metrics like the burn multiple can help you make informed decisions to extend your runway and align your growth ambitions with financial stability.

While it’s a simple calculation at face value, a cash runway analysis is nuanced and unique to every startup and can be impacted by a multitude of circumstances.

To calculate this, you just divide your total cash reserves by the amount you’re spending each month. Say you’ve got $250K in the bank and you’re spending $50K/month: 250/50 = 5. So you’ve got 5 months. Not 6. Not “it depends” – 5. That’s your runway.

Investors ask “If we don’t fund you, how long do you survive?” If you don’t know that answer, you're not fundraising – you’re freelancing with hope.

Here is a video that explains cash runway with real world examples and the thought process behind it.

And here’s an article from JP Morgan breaking down cash runway, its importance, and what can you to to maximize it.

Burn Rate vs Runway

So, let’s just make this super clear: burn rate is simply how much you spend each month to run your operation – that is, your negative cash flow. Runway is how many months there are left before your bank balance reaches zero.

So again, why do these numbers matter?

Because burn rate tells you how quickly you need to find more revenue or funding. Runway tells investors whether you are going to still be around by the time they finish their due diligence.

They are not just numbers. They are your survival clock.

Smart founders utilize these metrics to:

• Trim the fat without cutting muscle – know what to focus on and what to let go

• Forecast hiring/fundraising deadlines – know the process and prep for it. Numbers don’t line but they sure can get you ghosted.

• Assure investors you’re not going to come knocking again in 90 days – establishing credibility is key, make an investor realize its not just a hobby, you mean business.

The goal: Extend runway without stalling momentum. Keep the plane in the air, while building a bigger engine.

3. CAC (Customer Acquisition Cost): How Much Does it Cost to Convince Someone to Pay You?

Cost of acquisition refers to the entire cost that a business incurs to obtain a new client or asset. This includes the purchase price, shipping, installation, and marketing costs for the asset acquired. CAC takes into account the total expenditure on all marketing, advertising, and sales for the period, which you then divide by the number of new customers for the period.

In this case, all the upfront costs incurred to purchase a business asset, including equipment or inventory, are part of the cost of acquisition. Cost of acquisition includes:

• Purchase price of the item

• Costs to ship it to its point of use

• Costs to install the item

• Costs to get it up and running (in the case of equipment) or ready for sale (in the case of inventory) condition

• Marketing sales teams salaries

• All sales and consulting marketing expenses geared to get new consumers should all be included

Formula:
CAC = (Total Marketing + Sales Expenses) / Number of New Customers Acquired

Say you spent $10K last month across paid ads, content creation, outbound campaigns, and sales team costs. You onboarded 100 new customers, so your CAC = $100.

But is that good?

It depends on:

• Your pricing model (one-time vs. subscription)

• Your margin (how much of that sale do you actually keep?)

• Your customer retention (how long do they stick around?)

If you’re selling a $20 product once, a $100 CAC is a non-starter. But if that customer brings in $50/month for 12 months, you’ve got a solid return.

Watch for red flags:

• CAC is rising but revenue isn’t

• You’re overly reliant on paid ads (especially if organic/referral is flat)

• You don’t know CAC by channel (averages hide leaks)

A healthy CAC is one that pays itself back quickly and can be improved over time as you optimize funnels and messaging

Here is a video that breaks down CAC for you.

4. Customer Lifetime Value (LTV): How Much is One Customer Worth Over Time?

Customer Lifetime Value is the average monetary value of each customer to your business. LTV takes into account how much a unique customer is expected to spend with your business. It’s an important metric so you know how much new customers are worth to your business over their lifespan as a customer.

Let’s say you charge $25/month. The average customer sticks around 12 months.
LTV = $300.

In this case, if your CAC is $80? You’re in the green. But if it’s $350? You’re basically paying people to hang out (and losing money on them).

Now, let’s connect this to CAC.

Say your CAC is $80. You’re doing fine – your LTV is ~4x CAC. That’s what investors want to see.

Rule of thumb: you want your LTV to be at least 3x your CAC. A 1:1 ratio means you’re barely breaking even, before operational costs and the math stops working at scale. So if you can hit a 3:1 ratio, great – and based off my experience, your business will be much more appealing if it’s closer to 5:1.

And keep in mind that different models can have different thresholds. For example, a SaaS company with low churn can afford higher CACs, while an e-commerce platform might need faster payback. And marketplaces and freemium models may have lower LTV per user, but they can often more easily offset it with volume.

If you don’t know your LTV or can’t defend it with data, it becomes hard to justify spend – and easy for investors to walk.

If you want to know more, this video walks you through the basics.

And here’s a video that beautifully explains the CAC and LTV relationship.

5. Gross Profit Margin: What Do You Actually Keep After Delivering Your Service or Product?

Gross profit margin shows the amount of money a business collects after it pays for all its expenses. It’s usually calculated as a percentage of sales. This specific metric is also referred to as the gross margin ratio.

Companies use gross margin as a measure of how production costs relate to revenue. If a company's gross margin falls because it is making less revenue, it may try to cut labor costs, find cheaper suppliers of materials, or increase prices to increase revenue.

Gross profit margins can also allow a business to measure how efficient a company is, or compare two very differently sized companies that share a common revenue stream or product

If you sell a subscription for $50/month and it costs you $10/month to host, maintain, and support it, your gross margin is 80%.

• Good: SaaS companies often hit 70–90%.

• Bad: If you're below 30%, your "scalable" business will collapse under weight.

Want to know the conceptual math behind this metric and how it differs from Profit Margin? Here is a fantastic video that easily breaks it down.

6. Monthly / Annual Recurring Revenue (MRR / ARR)

Annual recurring revenue (ARR) is revenue a company expects to see from its product and service offerings, calculated over the course of a year. Companies that sell annual subscriptions like using ARR as a sales metric to track what they anticipate making in a year.

ARR tends to be used if companies sell a product or service in the software as a service (SaaS) space, but it can also be useful in terms of streaming services, cell phone bills, and (almost) anything else with a predictable, recurring charge.

ARR is calculated annually, whereas monthly recurring revenue (MRR) is calculated monthly. MRR is useful in that it shows what’s happening on a month-to-month basis. For example, if you change your price in April, you can see the immediate effects of that change in May. MRR also helps track fluctuations in revenue based on outside factors like holiday shopping seasons and economic conditions.

In a nutshell, Monthly / Annual Recurring Revenue = predictable income.

If you’re pulling $20K/month in subscriptions, that’s $240K ARR. Simple.

What investors care about:

• • Is it growing?

    • How fast?

    • And how stable is it?

Here is a founder breaking down the metric and explaining the relationship between MRR/ARR.

7. Churn Rate: How Fast Are Your Users Leaving

The churn rate, also known as attrition rate, represents the rate at which a customer stops doing business with a company. Customer churn is typically expressed as the percentage of service subscribers that discontinue their service subscriptions within a time frame. Churn can also be expressed as the rate at which employees leave their jobs in a given time.

In order for a business to grow its number of clients, its growth rate (which takes into account new customers) must be higher than its churn rate.

The benefit of calculating a churn rate is that it can clarify how well a business is retaining its customers, which is a measure of the quality of service the business is providing and the usefulness of that service.

When a business can see its churn rate increasing from period to period, this suggests that a critical aspect of how it is running the business might be problematic or flawed.

It could be the result of:

• A faulty product(s)

• Bad customer service

• Costs exceed utility to customers

And so on.

The churn rate will indicate to a business that it needs to learn why its customers are leaving, and where it needs to adjust its business. It’s more expensive to attract new customers than it is to retain them, so reducing the churn rate can save a business resources in the future.

Real talk: Say you had 500 users at the start of the month, and you lost 50 by the end of the month. That’s 10% churn – which is high! Annualize that and…ouch. You're not growing. You're replacing.

Make sure you fix this before you fundraise. Or at least explain why churn’s high and what you’re doing to plug the holes.

Here is a video that beautifully explains Churn Rate.

8. Payback Period: How Long Before You Recover Your CAC?

The payback period is a popular tool for determining investment return. People invest money for the purpose of getting it back and generating a positive return on the money they invested. The shorter the payback period, the more beneficial the investment will be.

The payback period does not factor in the time value of money. You can determine it simply by counting the number of years until the principal paid in is returned.

This metric measures how quickly your customer pays you back for the cost of acquiring them. The payback period doesn’t take into account the total profitability of an investment. It’s just concerned with paying the investment back.

There are two common interpretations:

1. Customer-Level Payback: If your CAC is $250 and your customer pays $50/month, it’ll take 5 months to recover the acquisition cost.

2. Investment-Level Payback: You spend $100,000 on a new sales hire, tool stack, or feature. You want to know how long it takes for that investment to generate $100,000 in profit.

Both use the same principle: the shorter the payback period, the less cash you need to float your growth.

If you want a target, aim for 6 months for customer-level payback. Closer to 3-6 is ideal. Long payback periods mean you need deep pockets – or exceptional retention – to stay afloat.

Here’s a video where you can learn more.

9. Earnings Before Interest, Taxes, Depreciation, and Amortization (EBITDA)

EBITDA stands for Earning Before Interest, Taxes, Depreciation, and Amortization. You can think of this as just your company's operating profit if you wanted a very rudimentary way of referring to it.

It’s not flashy. It’s not fun. But it tells investors: “Here’s what we really make once the accounting fog clears.” and “Are we generating real profits from our actual operations?”

EBITDA is what investors look at because it is the best way of comparing apples to apples when considering startups. EBITDA can provide investors a measure of your operational health.

A negative EBITDA for an early stage company isn't going to raise any eyebrows. Just don’t act surprised when someone brings it up. You need to do that math before the pitch. But, if you have a growing early stage company that's moving from negative EBITDA to positive? Now your getting into grown folks business.

Here’s a video that explains the basics of EBITDA.

And here’s another video that explains how investors look at EBITDA and its value in determining your business’s worth.

10. Valuation: What’s Your Company Worth – and What Supports that Number?

Valuation is a focused exercise that determines the value of an asset, investment, or company. So, how much your company’s worth. And the goal is typically to determine whether that value is a fair value.

Valuations can be conducted in one of two ways:

• an absolute valuation, which evaluates a company on its own merits and entirely independently of other factors/companies, or

• a relative valuation, which evaluates the company relative to other similar firms, or assets, in the same sector or industry. This determines if the company, or asset, is worth that much relative to others.

Depending on how the analysis and conclusions are reached, there are a variety of methods and techniques used to develop valuations. And as you’d expect, there’s often significant variability between outputs (or valuations) based on the inputs and context.

While valuations are predominantly quantitatively driven, there’s often a significant subjective influence that come from the assumptions and estimates made along the way. Valuations are also subject to developing situations and events outside of the analysis or the control of the analyst – for example, earnings reports or material news, or economic news – that can result in a change to a valuation stance.

If you’re pre-revenue and you’re saying $30M because a friend raised at that, please stop. Their experience likely has nothing to do with yours.

Valuation = traction + market comps + revenue + momentum + team.

Valuation isn’t just about what you want – it’s about what you can defend.

Startups are typically valued using:

• Comparable Analysis (Comps): What similar companies are worth

• Discounted Cash Flow (DCF): Projecting future cash and discounting it back

• Revenue Multiples: Often 5x–10x for SaaS, but varies wildly

• Precedent Transactions: What investors paid in past rounds for similar startups

But that’s the math.

Here’s the messy truth: Valuation = Traction + Team + TAM (total addressable market) + Timing + Storytelling.

Hard factors:

• MRR/ARR

• Growth rate

• Churn

• CAC:LTV

• Gross margins

Soft factors:

• Founding team’s track record

• Market momentum

• Hype or scarcity

Don’t inflate. Don’t anchor to your friend’s raise. Know your comps. And show why your model is defensible, not just desirable. Inflated numbers make investors run. They don’t correct you – they just ghost you.

There are numerous books written on valuation and each technique could be its own PhD. But my role here is to give you a sneak peak into the metrics.

Here’s a basic video on valuation if you’re interested in a deeper dive.

And here’s a more detailed video course outlining different forms of valuation. Professor Damodaran from New York University is considered to be one of the aces and thought leaders when it comes to valuation. In this video course he explains stepwise and beautifully so you can understand and explore the fascinating world of valuations.

Real Talk Before You Close That Tab

Real Experience

I met a founder once – early days, rough product, but you could tell he actually cared. He wasn't trying to look good. No buzzwords. No "disrupt" talk. Just someone trying to solve something annoying and important.

He walked into the room with a twinkle. Not swagger – just that gentle intensity. We were leaning in.

Then, in the middle of the pitch, someone asked, "So what's your monthly burn?" And I swear to you, he said, "Umm... I think my co-founder has that. I haven't looked in a while."

That was it.

No freak out. No awkward pause. Just... a cluck. Like a window closing in the background.

The product? Still smart. But the moment? Gone.

Nobody was mad. Nobody laughed. We even said thank you. But nobody followed up.

Why? Because it didn't feel like a business. It felt like a maybe.

Why This Matters

I’ve seen so many versions of that same scene play out. It’s never about charisma. It’s not even about the idea, half the time.

It’s about whether the person asking for money actually knows what they’re building. Not the dream, the mechanics. The guts, nuts and bolds of the business. The ugly Excel math nobody brags about on Twitter.

Unfortunately, no simple pitch deck will do that part for you. No co-founder can answer those questions on your behalf.

If it’s your vision, own the math. If it’s your company, learn the cost of keeping it alive.

The rest? The logos, the taglines, the “go-to-market” plans?.... All of that’s just packaging.

And you don’t have to be perfect either. You just have to be in it. Eyes open. Numbers in your head.
Because if you’re asking people to believe in what you’re building, you’d better believe in the scaffolding holding it up.

So yeah, know your CAC. Your LTV. Your margins. Your churn. Not to check some box on an investor’s sheet, but to prove to yourself and the investor that the thing you’re spending your life on…has legs. That it can stand. And run.

And maybe, someday, outlast you. Maybe!

Conclusion and Final Thoughts

I hope this was helpful to you, especially if you’re a founder or aspiring founder trying to build the next big thing. While there a many more ratios and concepts, these are the crux of them.

A lot of other complex ratios and valuations are either built using these metrics or refer them in some way. And each of these metrics could be an article of its own. But I wanted to give you my top 10 run down so that you could get a head start. Numbers are very much a part of the ideation stage itself, and omitting them from your strategy could prove to be a fatal mistake.

I’ll leave you with one last video on How to Start a Start Up with Michael Seibel (Reddit, YC, Twitch) that I hope you find valuable. It lays out, in a crash course format, the mindset of a founder who has been there and done that. The fun fact is that a lot of the themes he speaks of tie in to the metrics here, directly or indirectly.

I hope this gives you a perspective of being on the other side, evaluating your hard work and passion, and I hope it sets you up for success in your next Investor Review.

I look forward to your thoughts, comments, and feedback. If this was helpful, engaging, and informative, do share it – you never know who may need it, or could benefit from it. I wish you all the very best in your funding rounds.

Until then, keep learning, unlearning, and relearning, folks.

Then I joined a real team.

Suddenly, I was introduced to this thing called Kanban – and I realized I’d been treating software like a solo art project, not a process.

If that sounds familiar, you’re in the right place.

This guide will walk you through how Kanban actually works, how developers use it to track and prioritize work, and how it can help you stay sane when juggling bugs, features, and real-world deadlines.

Without further delay, lets get into it.

Here’s what we’ll cover:

• So… What Is Kanban?

• The Classic Kanban Board: Three Simple Columns

• How Developers Use Kanban in Real Life

• Kanban vs Scrum: What’s the Difference?

• So which one should you use Scrum or Kanban?

• What Tools Do Teams Use for Kanban?

• How to Use Kanban to Manage Your Own Coding Projects

• Final Thoughts: Why Kanban Isn’t Just a Board

So… What Is Kanban?

At its core, Kanban is a visual way to manage work. It helps teams (or team members) see:

• What needs to get done

• What’s in progress

• What’s finished

• Where things are getting stuck

The concept comes from lean manufacturing, but in tech, it’s often used in Agile teams that need flexibility without the structure of Scrum sprints.

Think of Kanban like a whiteboard that tells a story. Not just what’s done, but how work flows.

The Classic Kanban Board: Three Simple Columns

So what exactly is a Kanban board? At its core, it’s a visual representation of your workflow – a board that shows all the work your team (or you, solo warrior) are juggling, and where each task stands.

It can be physical, like an actual whiteboard with sticky notes that move from one column to the next. Or digital, using tools like Trello, Jira, GitHub Projects, or Notion. The key is that it’s visual and up-to-date. You can walk into a room or open a tab and instantly understand: What’s being worked on? What’s ready to go? Where are things stuck?

It’s like having your brain on a wall, but organized. And slightly less chaotic.

The beauty of Kanban is how dead simple it is to get started. At minimum, your board has three columns:

Each task – or card – moves from left to right as it gets worked on.

Let’s say your team is building a blog platform. Your Kanban board might have cards like:

• “Create signup form”

• “Fix image upload bug”

• “Deploy staging build”

Now, while Kanban is flexible, it can absolutely be taken too far.

I’ve seen boards with more columns than a Greek temple: “Needs Review,” “Pending Client Feedback,” “QA Rework Round 2,” “Blocked but Still Hopeful,” “In Existential Limbo,” and so on. Every card had six tags, three owners, two checklists, and one migraine.

The lesson? Don’t turn your board into a bureaucratic jungle.

You don’t need to account for every edge case. Start simple: “To Do,” “In Progress,” “Review,” “Done.” These basic stages cover most workflows. If you discover a real need for something more – like a dedicated “QA” column or “Blocked” column – add it intentionally, not because you feel like your board needs to look fancy.

Remember: A Kanban board should be helpful, not overwhelming. If you spend more time managing the board than doing the work on it… it’s doing the opposite of what it’s meant to do.

How Developers Use Kanban in Real Life

Here’s how you might interact with a Kanban board on a dev team:

1. You pick up a card from “To Do” – let’s say, “Add dark mode toggle.”

2. You move it to “In Progress.”

3. When it’s ready for review, you might move it to a temporary “Review” or “Testing” column.

4. Once it’s merged, tested, and deployed, you move it to “Done.”

5. You smile, drink some coffee, and grab the next card.

That’s it. But over time, this process helps the whole team:

• Spot bottlenecks

• Prevent duplicate work

• Reduce context switching

• Keep everyone aligned

What’s a WIP Limit — And Why Should You Care?

WIP = Work In Progress. This is the most important concept to keep us in check.

One of Kanban’s key principles is limiting how many things you’re working on at once. Because guess what? Multitasking kills momentum.

A typical WIP limit might look like:

• No more than 2–3 cards per person in “In Progress” Again this is best practice, but folks do pick up a lot and then they end up being the bottleneck.

• No more than 5 tasks waiting on QA.

Why? Because when everything’s urgent, nothing gets done. WIP limits force you to finish one thing before you start more – and that’s how real velocity happens.

If there are more than 5 tasks in the “To Do” column, the team doesn’t take up new ones. Instead, everyone chips in to see how they can help unclog the bottleneck. A bottleneck is your worst enemy in Kanban, and you want to resolve it so items move smoothly on time and on target.

Here’s a video recapping key concepts.

Kanban vs Scrum: What’s the Difference?

You’ve probably heard Scrum and Kanban mentioned in the same breath – and both are popular Agile frameworks. But they’re not interchangeable.

Scrum is structured, with roles like Product Owner and Scrum Master, and work gets organized into time-boxed sprints. It’s perfect for teams that benefit from rhythm and rituals – like sprint planning, daily standups, and retrospectives.

Kanban, on the other hand, is a little looser. No official roles, no set sprint timelines. Work flows continuously, and change can happen anytime. It’s perfect for teams who need more flexibility and fewer ceremonies.

So how do they compare in practice? Let’s break it down:

Bottom line:

• Scrum is a scheduled loop. Kanban is a living flow.

• One’s a playbook. The other’s a status window.

Here’s a video on the main differences between Scrum and Kanban you can watch if you want more detail.

So which one should you use Scrum or Kanban?

So… which one should you use?

It really depends on your team, your product, and your pain points.

✔️ If you’re working on a brand-new product where requirements shift a lot, and your team thrives with structure and routines – Scrum is likely the better fit. Sprints give you a sense of pacing, and ceremonies help ensure alignment.

✔️ If you’re managing ongoing work like bug triage, tech debt, infrastructure tasks, or anything that’s more “whenever it comes in” than “we need to ship this in two weeks” – Kanban gives you flexibility and visibility without the overhead.

And yes, there’s such a thing as Scrumban – a hybrid approach where teams use visual boards and WIP limits from Kanban, but keep some of Scrum’s structure like standups and retros. It’s like Agile tapas: you get the flavors that work best for your appetite.

Here is a detailed video that’'ll teach you more about how Scrumban works in practice.

Watch the Scrumban video only when you are familiar and comfortable with both Scrum and Kanban – otherwise, you might get confused from the cross-pollination of ideas and frameworks.

I personally have never seen a Scrumban implementation thats scaled well – too many folks trying too many things and none of them work. But thats just based on my experience – it may work for you and your team. I’ll let you be the judge.

What Tools Do Teams Use for Kanban?

You’ve probably seen (or used) one already:

• Trello – Simple and great for solo or small teams

• Jira – Enterprise-level, customizable workflows

• GitHub Projects – Lightweight but powerful for devs

• ClickUp / Asana / Notion – Integrated with docs/tasks

Kanban isn’t tied to any one tool – you can use an app, a browser tab, or a whiteboard and a pack of sticky notes from the office supply closet. What matters is how you use it. But let’s walk through some of the most common tools and what they offer in a Kanban context:

🟩 Trello

Trello is probably the easiest way to start with Kanban. It gives you a simple digital board with columns and cards you can drag and drop. It’s great for devs or small teams who don’t need tons of automation – just a clean place to track work visually.

🟨 Jira

Jira is a heavyweight – and while it’s built for Scrum, it also supports robust Kanban boards. You can define custom workflows, use built-in reports like cumulative flow diagrams, enforce WIP limits, and manage team velocity. Ideal for large teams that need traceability, integrations, and permissions.

🟦 GitHub Projects

If your code lives in GitHub, GitHub Projects is a clean way to stay close to your codebase. It lets you create Kanban-style boards with issues and pull requests as cards, so you’re never toggling between tools just to track what’s in progress.

🟧 ClickUp / Asana / Notion

These are all-in-one productivity platforms. They combine Kanban boards with documentation, team chat, calendars, and reporting. If your team needs more than just “move card left to right,” these tools let you manage projects, meetings, notes, and workflows in one place.

🟪 Whiteboard + Sticky Notes

Don’t underestimate the analog approach. It’s fast. It’s visible. It’s tactile. Physically moving a task from “Doing” to “Done” gives you a sense of progress no digital tool can match. And when something’s blocked? Slap a red sticky on it and call it a day.

Bottom line: The best tool is the one your team will actually use. Fancy doesn’t beat consistent. And the actual tool doesn’t matter as much as the discipline your team has to actually use it.

How to Use Kanban to Manage Your Own Coding Projects

Even if you're not on a team yet, Kanban is great for your own workflow. Here’s how you can use it to help yourself out:

1. Create a basic 3-column board (To Do, In Progress, Done)

2. Write out every task, big or small

3. Set a WIP limit (for example, no more than 2 tasks at once)

4. Update it daily. Make it a ritual.

5. Review your flow weekly – What got stuck? What moved fast?

Example:

You’ll be shocked how much clearer your thinking gets when you can see your work. It’s simple but super powerful to visualize your work it in this way.

Final Thoughts: Why Kanban Isn’t Just a Board

Kanban isn’t just a tool – it’s a mindset.

It helps you focus. It helps your team collaborate. And it gives everyone – even non-technical folks – visibility into what’s going on.

If you’re learning to code and want to feel more confident working with others, learning Kanban is low-effort, high-impact.

So don’t wait until your first job. Start using it now – and show up to that standup with confidence.

I hope this small 101 Guide to Kanban was helpful to you all. My sole purpose to write this was to help beginner developers understand Kanban as a practical workflow system – especially for those transitioning from solo coding to collaborative, real-world development environments. It aims to demystify the methodology in a casual, beginner-friendly tone while still offering actionable guidance.

I hope you enjoyed my beginners guide to Kanban.

Until next time, keep Learning, Unlearning and Relearning, folks….

You’ve been grinding through tutorials. You've built a portfolio site, maybe deployed a few projects on GitHub. And now you're trying to land a job or join a team.

Then the interviews start.

Suddenly, people ask:

• "Are you familiar with Agile?"

• "Have you worked in a Scrum environment?"

• "What’s your experience with sprints?"

Cue the imposter syndrome. Because no one teaches this stuff in JavaScript 101.

This guide is for you.

I’ll help make the Scrum process – a very common way developers work together – make actual sense. I’ll walk you through the basics, but also tell you what developers actually do, how standups feel when you're new, and what’s expected of you when you’re no longer coding in a vacuum.

Let’s break it down.

Here’s what we’ll cover:

• What Even Is Scrum?

• The Three Roles in Scrum (and Who Does What)

• The Scrum Rhythm: What a Sprint Actually Looks Like

• Who attends the Ceremonies:

• Standups: Where You Talk Like a Human, Not a Robot

• Sprint Planning

• What’s a User Story and Why Does It Sound Like a Children’s Book?

• What Counts as “Done”? Definition of Done and Why It’s Important

• Demos, Retros, and Saying the Hard Things

• Tools You Might Encounter

• If You’re Preparing for a Job, Here’s What You Can Do

• Final Thoughts

What Even Is Scrum?

Scrum is not a tool. It’s not a software. It’s not some elite thing only PMs care about.

It’s a lightweight framework that helps software teams build things incrementally, together, in short focused cycles called sprints.

Scrum is used by everyone from FAANG teams to indie dev shops because it helps:

• Keep teams aligned

• Deliver working software fast

• Course-correct often

• Spot problems early (before they go nuclear)

It’s the opposite of the old-school “build for a year and pray it works” model.

The Three Roles in Scrum (and Who Does What)

Scrum officially defines three roles. Here's what that means in practice:

1. Product Owner (PO)

Think: Vision-holder. They decide what the team builds and why. A product owner:

• Writes user stories (think of these as feature requests written from a user’s point of view)

• Prioritizes the work

• Clarifies what success looks like

• Says “yes” or “not yet” to features

2. Scrum Master (SM)

Think: Air-traffic controller meets therapist. They make sure the process works. The are master Facilitators, like between Dev and PO’s. A Scrum Master:

• Facilitates meetings

• Removes blockers (“Your AWS access is stuck? I’ll escalate it.”)

• Coaches the team on Scrum practices

• Doesn’t manage people – manages flow

3. Developers (YOU!)

Think: Builders. You write code, test it, ship it, fix it, and improve it. You also:

• Break down stories into tasks

• Pick up work from the team board (like Jira or Trello)

• Communicate progress

• Demo what you’ve built at the end of the sprint

You might also work with designers, testers, or DevOps folks – but within Scrum, you’re all “developers” building a product together.

The Scrum Rhythm: What a Sprint Actually Looks Like

Image Source: https://www.invensislearning.com/blog/what-are-scrum-ceremonies/

Understanding the Scrum Cycle

So, what does it actually look like when a team uses Scrum to build software?

Let’s walk through a full sprint – not just the buzzwords, but what really happens when a group of humans tries to plan, build, review, and improve together. Think of this as your backstage pass to the rhythm of modern teamwork.

📦 Step 1: Build and Refine the Product Backlog

Before any coding starts, the team needs to agree on what they might build – not just this week, but in the near future too.

That’s where the Product Backlog comes in. This is a big, running list of everything the product might need – features, bug fixes, improvements, ideas, and maybe a few wild dreams. It’s like the wishlist for the product, but more organized (ideally).

The Product Owner is responsible for maintaining and prioritizing this list. They decide what’s most important to work on based on customer needs, business goals, and feedback.

But the PO doesn’t do this in isolation. Enter the Backlog Refinement meeting.

In these sessions, the Scrum Team – that’s the PO, the Scrum Master (SM), and the Developers – come together to:

• Review the most important upcoming items

• Clarify any vague or confusing parts of each task

• Break big items down into smaller, buildable pieces called user stories

• Estimate effort (how much time or complexity is involved for each story)

This meeting makes sure the team isn’t caught off guard in the sprint – that they understand the work ahead and can actually start sprinting when the time comes.

🧭 Step 2: Sprint Planning – What Are We Building This Time?

Now that we’ve got a solid backlog, it’s time to pick what to build right now.

At the start of each sprint (which typically lasts 1 to 4 weeks), the team holds a Sprint Planning meeting. This meeting sets the stage for the entire sprint – it’s like the huddle before the big game.

In Sprint Planning, the team:

• Reviews the top items from the backlog

• Discusses what can realistically be completed based on their availability and capacity

• Chooses a handful of these stories to commit to

• Defines a Sprint Goal – a simple statement that captures the purpose of this sprint

For example, the Sprint Goal might be:
🎯 “Allow users to reset their passwords.”

Every user story chosen should contribute to that goal. The collection of these stories becomes the Sprint Backlog – basically, the to-do list for the sprint.

So when we say:

“The team selects an ordered list of user stories to comprise the Sprint Backlog for the next sprint, which will be achievable to satisfy the Sprint Goal...”

We’re really just saying:
👉 “Pick a realistic number of important tasks that, if completed, will help us hit our target for the sprint.”

Not too vague. Not too ambitious. Just achievable and focused.

☀️ Step 3: Daily Standups – Stay in Sync

Now the sprint is underway! But how does everyone stay aligned and avoid working in silos?

That’s where the Daily Standup comes in. Every day – usually in the morning – the team has a quick check-in (about 15 minutes) where each person answers three questions:

1. What did I do yesterday?

2. What am I working on today?

3. Is anything blocking me? (that is, am I stuck?)

Example:

“Yesterday I set up the login API integration. Today I’ll work on the UI validation. I’m blocked on getting access to the staging database — may need help.”

These standups keep the team in sync and surface blockers early so they can be addressed quickly. They’re not about micromanaging or showing off. They’re about visibility and support.

📉 What’s a Sprint Burndown Chart?

You might hear your team mention a “burndown chart.” No, this isn’t about things going down in flames (hopefully).

A Sprint Burndown Chart is a graph that shows how much work is left in the sprint – day by day.

• The y-axis is the amount of work remaining (often measured in story points or tasks)

• The x-axis is the number of days left in the sprint

The line should ideally trend downward as work gets completed – hence “burning down.” If it flattens out or slopes up, that’s a red flag that the team might be stuck, behind schedule, or not updating the board.

Think of it as a visual heartbeat of the sprint. You can learn more via a practical example in this video.

🖥️ Step 4: Sprint Review – Show What You’ve Built

At the end of the sprint, the team holds a Sprint Review (also called a “demo”). This is where you show what was actually built during the sprint.

• The Developers demo working features – live, not just screenshots

• The Product Owner reviews whether the Sprint Goal was achieved

• Stakeholders may ask questions, give feedback, or suggest tweaks

This meeting isn’t just for show – it’s a feedback loop. It helps the team validate that what they built is useful, usable, and meets expectations. If changes are needed, those get added to the backlog for future sprints.

🔍 Step 5: Sprint Retrospective – Look Back to Move Forward

Once the review is done, the team shifts focus from what they built to how they worked together.

Enter the Sprint Retrospective – a meeting to reflect on the process, not the product.

The team discusses:

• ✅ What went well

• ❌ What didn’t go so well

• 🔁 What could be improved next time

This isn’t about pointing fingers. It’s about learning, adapting, and continuously improving how the team collaborates.

The Scrum Master often facilitates this meeting and helps turn feedback into action items for the next sprint. For example:

“We underestimated testing time. Next sprint, let’s budget for QA earlier.”

The best teams take retros seriously. Why? Because even if your code is perfect, your process needs tuning too – and small process changes often lead to big gains.

♻️ Scrum Is a Loop

Here’s the rhythm:

1. Plan the sprint

2. Check in daily

3. Build and demo the product

4. Reflect and improve

Then do it all over again – with slightly better coordination and slightly more trust each time.

It’s not about being fast. It’s about being intentional, consistent, and collaborative.

Example Sprint

Let’s say, for example, that your team does 4-week sprints. (Keep in mind that Sprints can differ by team, nature of product, release cycles, and so on.)

Here’s the rough beat:

Scrum works in loops. Every 2-4 weeks (depending on your cadence and sprint cycle), your team should have working, demo-able software to show for it – even if it’s small.

And no, it’s not about “speed.” It’s about consistency, communication, and collaboration.

Who attends the Ceremonies:

Now lets dive deeper and understand practically how each of these ceremonies work:

Standups: Where You Talk Like a Human, Not a Robot

So how does the team actually stay connected day to day? That’s where standups come in.

Every morning, your team meets briefly – usually on Zoom or in a circle – and you answer 3 questions:

1. What did I work on yesterday?

2. What will I work on today?

3. What’s blocking me? Any impediments?

Example:

"Yesterday I cleaned up the signup validation logic. Today I’m working on the email verification flow. I’m stuck on SendGrid config – might need help setting up credentials."

It’s not about impressing anyone. It’s about keeping everyone in sync. Some days you’ll say, “I spent the whole day debugging a CSS bug that turned out to be a semicolon.” That’s okay.

How does it work?

The Scrum Master gathers everyone in a huddle room, the PO and Dev Team included, and opens the the Standup. They are the facilitator of the ceremony. Everyone gets a chance to answer the 3 questions above (usually about 2-5 minutes each). It’s not a full report – it’s quick. When one person is done, they pass it on to someone else.

This ensures there is team cohesion and transparency.

Here is a video example of a standup.

Sprint Planning

The goal of the planning meeting is to answer the questions “What are we going to work on, and how are we going to do it?” It is critical for the team to have a shared goal and a shared commitment to this goal before beginning this ceremony.

Participants should:

• Measure growth

• Sync with the Scrum Master

• Sync with the Product Owner

Sprint planning happens just before the sprint starts, and usually lasts for an hour or two. In this meeting, the team goes over a collection of user stories and discuss, plan, measure, and prioritize. This is where they decide what is going to be in scope for their upcoming sprint cycle.

The Product Owner will have a prioritized view of things in the backlog. They work with the team on each object or customer experience. Together, as a group they go through and make calculations, deciding to what they can commit.

What’s a User Story and Why Does It Sound Like a Children’s Book?

So you might be wondering: how do you know what to work on? What to build? So much work, so little time? Thats where user stories come in.

In Scrum, teams don’t just write vague tasks like “code the login.” Instead, they write user stories – short, human-centered feature descriptions that describe what the user needs, why they need it, and what success looks like.

Here’s an example:

As a user, I want to be able to reset my password, so I can access my account if I forget it.

User stories are the scaffolding of teamwork. They’re written with empathy, not just efficiency. And each one comes with acceptance criteria – a checklist that clarifies what “done” actually means:

• A “Forgot Password” link is visible

• Clicking it shows a form

• An email gets sent with a reset link

Once a story is agreed upon, developers break it down into tasks, like “build form,” “hook into backend,” or “handle email validation.” It’s collaborative, not prescriptive. And user stories have priority so you know what’s the most important and what’s the least.

A helpful rule of thumb many teams use is the Gherkin-style "Given–When–Then" format:

• Given some initial context

• When an event occurs

• Then a specific outcome should happen

This ensures that everyone – devs, testers, and product owners – shares the same understanding of behavior and expectations.

Here is a great video example thats outlines how to draft effective and powerful user stories.

What Counts as “Done”? Definition of Done and Why It’s Important

Now you might be wondering – how do I know when a task is done and can be closed out?

The Definition of Done is a type of documentation in the form of a team agreement. The Definition of Done identifies the conditions that need to be achieved in order for the product to be considered done (as in potentially shippable).

This is how we know that we "did the thing right". Meaning, we built the correct level of quality into the product. The Definition of Done is not the same as the acceptance criteria, which are written by the product owner to help us know we did the "right thing".

Every team has a Definition of Done – it’s not just “I pushed code.” It could mean:

• Code is written

• Reviewed by a peer

• Merged into main

• Tested on staging

• Possibly deployed

This clarity keeps teams honest and accountable. No “it works on my machine” energy here. The DoD sets a quality bar. It prevents ambiguity, rework, and “it works on my machine” moments. When every card on the board passes the same finish line, teams move faster – and trust each other more.

Everyone should know what done is in a team. Either its Done as per DoD standards or its not.

Here is a beautiful video highlighting the impotence of DoD.

Demos, Retros, and Saying the Hard Things

Once you’ve built the product, then comes demos (showcasing your work) and retros (analysis as a team on what when well and what areas to improve on).

In the retro, everyone’s encouraged to speak up:

• What went well?

• What didn’t?

• What should we try next time?

Example:

“We missed a lot of stories because we didn’t account for testing time. Maybe we buffer next sprint with fewer tasks.”

The goal is not to blame – it’s to improve. Over time, this feedback loop becomes gold. The Scrum Master usually facilitates, collects feedback (via tools like Parabol, Miro, or sticky notes), and helps turn insights into actionable experiments for the next sprint.

Over time, retros become the heartbeat of team evolution.

Here is a video highlighting the importance of a Retro and Sprint Review.

🧠 Why Retrospection Matters More Than You Think

The Sprint Retrospective is more than just another meeting. It’s a mirror for your team – a safe, structured space to pause, reflect, and improve together.

You discuss:

✅ what went well

❌ what did not go well

🔁 what could we do better next time

Great teams don't just deliver great software, they continually deliver better ways of working.

This is why many experienced Scrum practitioners consider the retro to be the most important event in Scrum. Code is deployed once, but process improvements grow exponentially, sprint after sprint.

Tools You Might Encounter

Scrum doesn’t require software, but real-world teams use a variety of tools:

• Jira – Tracks sprints, issues, velocity

• Trello – Simple board, good for small teams

• Slack – Where standups often happen if async

• Notion / Confluence – Docs, retros, notes

• GitHub Projects – Lightweight planning for devs

Don’t worry if you’re not fluent in these yet. They’re tools – you’ll learn them on the job.

If You’re Preparing for a Job, Here’s What You Can Do

• ✍️ Practice writing user stories from your side projects

• 🧪 Run a mini-sprint: Plan your weekend project, set goals, and “review” it at the end

• 🤝 Contribute to an open-source project that uses Scrum or Agile workflows

• 🧾 Write about what you learned – maybe as a tutorial (hint hint)

Final Thoughts

So to recap, Scrum is a simple yet powerful way for teams to work together, stay organized, and deliver results quickly. It runs in short cycles called sprints, where the team plans what to do, checks in daily, shows their progress at the end, and reflects on how to improve.

The four key ceremonies – Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective – help keep everyone aligned and focused. With clear roles and regular feedback, Scrum makes it easier to handle changes, solve problems early, and continuously get better as a team.

But scrum isn’t a magic spell. It’s just a way for humans to build complex things – together – without falling apart.

You don’t need to be a Scrum Master. You don’t need a certification. But if you understand how sprints work, what’s expected of you, and how to show up to meetings with clarity and candor, you’re 10 steps ahead of most.

Scrum helps teams talk, plan, build, and learn. And now? You can too.

If you liked this, please do share. You never know who it might help out.

Until then…keep learning, unlearning, and relearning!!!

Maybe you’ve said it yourself.

In the rush to launch a feature, meet a deadline, or impress a client, you take a shortcut. The code works – for now. The design passes – for now.

But over time, these choices pile up. They slow you down. They make every change harder. That’s technical debt.

Technical debt is a quiet, creeping cost. It doesn’t show up in metrics like churn or conversion rate. But it eats away at your product’s quality, your team’s velocity, and your ability to innovate.

You don’t notice it right away. Then, suddenly, everything feels slower. Nothing is simple anymore.

One bug fix breaks two new things. Engineers groan when they touch certain parts of the code. That’s when you realize you’re in debt.

Let’s talk about what technical debt really is, how it forms, and how you can deal with it before it kills your product.

What Is Technical Debt?

Think of technical debt like financial debt. When you borrow money, you get something now – at the cost of interest later.

In software, it’s the same. You make a quick decision to save time now, knowing it might cost you more effort down the line.

There’s nothing inherently wrong with that. Sometimes, taking on debt is smart. You might need to ship fast to test an idea or respond to the market.

But if you keep borrowing and never repay, the interest builds. And technical debt doesn’t just grow – it compounds. The longer you leave it, the worse it gets.

You don’t just end up paying more later. You slow down your whole team.

Every new feature takes longer. Bugs multiply. Morale drops. And eventually, your product feels fragile. That’s when the real damage begins.

Types of Technical Debt

Not all debt is the same. Some is like a short-term loan – you know you’re taking it and why. Other debt is like a bad mortgage – no one even knows it’s there until things break.

Here are the most common types:

• Intentional debt — You cut corners to hit a deadline but log it and plan to fix it. This can be healthy if managed well.

• Unintentional debt — You didn’t realise the shortcut was harmful. Often happens with new tech or unclear requirements.

• Environmental debt — Your tools, libraries, or frameworks get outdated. Even if your code is clean, it sits on crumbling infrastructure.

• Process debt — The way you build software becomes inefficient. Poor handoffs, unclear documentation, or weak testing pipelines all contribute.

Recognising which type you’re dealing with helps you prioritise. Not all debt needs immediate repayment. But all of it needs attention.

How Technical Debt Happens

As you can probably imagine, technical debt shows up in many ways.

Sometimes it’s deliberate. You make a tradeoff. You know it’s a shortcut, and you plan to clean it up later. That’s manageable – if you actually clean it up.

But most technical debt isn’t planned. It sneaks in through decisions that feel small in the moment. A rushed feature. A new hire not trained on the codebase. A spec that changes mid-sprint. Over time, these small cracks become deep fractures.

Here’s a simple example:

// Temporary workaround for product discounts
function applyDiscount(price, productType) {
  if (productType === 'electronics') {
    return price * 0.9; // 10% off
  } else if (productType === 'clothing') {
    return price * 0.8; // 20% off
  } else if (productType === 'books') {
    return price * 0.95; // 5% off
  } else {
    return price;
  }
}

This started as a quick fix. But over time, new product types get added with more exceptions.

Soon, you will have twenty if-else branches. It’s fragile. Every change risks breaking something. That’s technical debt.

The worst part? You might not even notice until a year later, when a bug in that logic takes hours to trace. You wonder, “How did this get so messy?” The answer: one shortcut at a time.

A better long-term approach in the above example would be a configuration-driven system or a discount rules engine.

// Config-driven discount logic
const discountRates = {
  electronics: 0.10,
  clothing: 0.20,
  books: 0.05
};

function applyDiscount(price, productType) {
  const discount = discountRates[productType] || 0;
  return price * (1 - discount);
}

Why Technical Debt Can Be Dangerous

Technical debt slows you down. That’s its most visible cost.

A feature that should take a day now takes a week. Simple changes break unrelated things. Your team spends more time fixing than building.

But the real danger goes deeper. Technical debt makes you afraid to touch your code.

Engineers stop refactoring because “it’s too risky.” You start saying no to new ideas because the system can’t handle them. The product becomes rigid. You stop innovating.

It also hurts your team. Developers don’t like working in messy codebases. It leads to burnout. New hires struggle to onboard.

Your best engineers spend their time firefighting instead of creating. Eventually, people leave. And your debt remains.

How to Manage Technical Debt

You can’t eliminate all technical debt. But you can manage it.

First, treat it like real debt. Track it. Prioritize it. Make regular payments.

Start by writing it down. Every time someone takes a shortcut, log it. You don’t need a fancy tool – a shared doc or Jira tag works fine. Just make it visible.

Next, build time into your workflow to pay it off. Use 10–20% of each sprint to refactor or improve the codebase. Don’t wait for a rewrite. Small, steady work adds up.

Code reviews help too. Encourage your team to ask: “Is this a shortcut?” If yes, make a conscious choice. Leave a clear comment. Note the tradeoff. Now it’s not a hidden cost – it’s a known one.

And when you do pay off debt, celebrate it. Make it part of your culture. The same way you’d celebrate shipping a feature, acknowledge when your team makes the codebase better. That builds pride and ownership.

Knowing When to Refactor

You can’t fix all the debt at once. So how do you choose?

Look for signs of pain. If a file breaks every sprint, fix it. If one part of the system takes days to test, improve it. If new hires always get stuck in one module, clean it up.

Focus on the code you touch often. There’s no point polishing a dead feature. But if something is part of your core flow, invest in it.

Also, listen to your team. Engineers know where the pain lives. If someone says, “This part scares me,” take that seriously. Fear in the codebase is a red flag.

When Debt Becomes Fatal

Sometimes, the debt gets so bad that small fixes won’t save you. The system collapses under its own weight. Everything feels slow. Nothing is safe to change. That’s when teams start talking about rewrites.

But rewrites are risky. They take time. They often miss hidden business logic. And they can carry old debt into new code if not done carefully.

If you must rewrite, do it incrementally. Replace modules one at a time. Add tests. Migrate data with care.

And don’t forget why the old system failed. If you don’t fix the culture, the new system will rot too.

Final Thoughts

Technical debt isn’t evil. It’s part of building software. But like financial debt, it needs discipline. You can’t just ignore it and hope it goes away.

Great products aren’t just well-designed. They’re well-maintained. The teams behind them care about quality — not just in what users see, but in what engineers live with every day.

So the next time you say, “We’ll fix it later,” ask yourself: will you? Or are you just borrowing against the future?

Hope you enjoyed this article. Join my newsletter for similar articles and connect with me on Linkedin.

Machine learning and deep learning have been popular buzz words for the last five years. The demand for .ai domains has skyrocketed.

But beyond all the hype surrounding machine learning, it is hard to grasp the basic concepts with ease if you are an absolute beginner.

Given the pervasive nature of ML and AI, almost every product can have a machine learning use case now. So in this article, we'll look at machine learning in-depth and equip you with the knowledge you need for your next technical conversation.

What is Machine Learning?

Machine learning is a branch of Artificial Intelligence. Artificial Intelligence as a whole includes many general concepts that aim to simulate human thinking.

Machine learning focuses only on one key aspect: making machines learn.

Machine learning is the science of getting computers to make decisions without being explicitly programmed.

In the past decade, machine learning has given us self-driving cars, face recognition, chatbots, and many other useful applications. Machine learning is powering so many tools that we use on a daily basis.

How Does Machine Learning Work?

Machine learning uses algorithms to analyze massive amounts of data and draw conclusions from it. When you combine large data sets with high computing power, these algorithms can understand patterns and relationships between data.

For example, let's look at a simple dataset:

x = 1,2,3,4,5

y = 1,4,9,16,25

If you look at the above numbers, you'll see that the relationship between x and y is that y is a square of x (that is, y = x²).

In machine learning, the job of an algorithm is to find this function that defines the relationship between the input and output. Once this function has been established, it is easy to predict future values.

For example, if x is 10, y is 100.

Though this example is too simple, it should give you an idea of how machine learning models work.

Consider a complex dataset like predicting housing prices.

This dataset will contain area codes, square footage, and many other inputs with the price as the output. If you have a dataset with thousands of these input features and the final price, you can train a model to predict the average price based on new inputs.

Machine learning problems usually involve finding the relationship between the inputs and outputs to find the ‘hypothesis function’. In our earlier example, the hypothesis function was y = x².

Real-world hypothesis functions are much more complex than this. We then use that function to find answers for custom inputs.

In a nutshell, machine learning, in most cases, is advanced statistics combined with computational capacity. Today, machine learning powers technologies like facial recognition, sentiment analysis, and many others.

Types of Learning Algorithms

Let's look at the type of problems you will come across when working with machine learning. Firstly, there are three ways by which you can make machines learn.

Supervised Learning

In supervised learning, you provide clear inputs to a machine learning algorithm. The algorithm knows what to learn from the data and the conclusions expected from it.

For example, for recognizing the difference between a cat and a dog, you train an algorithm with thousands of images. Each of these images will be labeled accordingly.

Once you run this data through the algorithm, the algorithm learns and understands the differences. Thus, it can predict, with reasonable accuracy, whether a new image is a cat or a dog.

Unsupervised Learning

Labeling data is important to build a supervised model. However, companies collect large datasets on a daily basis. Labeling these datasets to make the job of a machine learning model easier is not an elegant way to approach this problem.

This is where unsupervised learning comes in. You can use unsupervised learning algorithms to cluster data based on available attributes. This data can then be fed into supervised learning models to achieve higher prediction accuracy.

Unsupervised learning models are more challenging than supervised learning models. You can find more information and examples here, and you can learn more about important machine learning algorithms here.

Reinforcement Learning

No machine learning algorithm is 100% accurate. The level of accuracy depends on the dataset you train the algorithm with.

This means that after you train an algorithm, there can be new datasets available. These datasets might have the potential to improve the accuracy of your model considerably.

You can use reinforcement learning for these types of scenarios. Reinforcement learning is the concept of updating the algorithm while it is in production. Reinforcement learning models can retrain based on new inputs.

For example, a self-driving car can learn about a new type of terrain after it has traveled through that terrain. This will be taken into account by the self-driving car’s algorithm the next time it has to choose a route.

Types of Machine Learning Problems

Machine Learning problems can be classified into four subcategories based on the type of result you are looking for.

Classification

Classification models produce a result that belongs to a finite set. Examples of classification models include spam/not spam, 0 or 1 (binary classification), positive/negative/neutral, and so on.

Regression

Regression models produce results that belong to a range. Examples include predicting stock market prices, weather forecasting, and more. These are not limited to a finite set of values and hence are called regression problems.

Clustering

Clustering is a key concept in unsupervised learning. Clustering helps you group data that have similar attributes. Once these groups have been established, it becomes easier to train them using supervised models.

Learn more about clustering here.

Dimensionality Reduction

Dimensionality Reduction is another unsupervised learning technique. Using Dimensionality reduction, you can reduce a complex dataset with thousands of features into a simple one with maybe a hundred inputs.

Similar to clustering, dimensionality reduction is often used to reduce noise from large datasets before feeding them into supervised training models.

You can find a more in-depth article on Dimensionality reduction here.

What is Deep Learning?

Deep learning is Machine learning on steroids.

There are many algorithms in machine learning. One that stands out is a Neural Network.

The difference between other machine learning algorithms and a neural network is that you can stack neural networks together — as many as you want.

This helps us solve complex problems like facial recognition and self-driving since these types of problems come with thousands of inputs in real-time.

Using neural networks, you can solve almost any complex problem with high accuracy, if you have the data and computing power needed for the model to run.

Neural networks have been around for decades, but it was the availability of large datasets and computing power that bought them back to life. Now deep learning is one of the most exciting fields in the industry.

Why Do You Need Machine Learning?

Let's look at some popular machine learning solutions that we use every day.

Voice assistants

Ever wondered how Siri can understand and interpret your voice commands? The answer is machine learning. You can find a voice assistant in almost every smartphone now, thanks to the advancements in Natural Language Processing.

Even though it is hard for computers to understand natural language, thanks to machine learning, we have Alexa, Cortana, and Siri.

Product recommendations

Recommendation engines are a profitable use case for e-commerce companies. If you can find the right products to recommend, chances are your customer will make multiple purchases.

Machine learning algorithms can understand user behavior from past purchases. This helps them recommend similar products when a customer is shopping on your website.

Recommendations are not limited to e-commerce. This applies to products like Spotify or Netflix that recommend the music or movies you like.

Chatbots

Customer support can make or break your company, especially if you are a startup. The more users you attract, the more customer support you have to provide.

Chatbots are a huge time saver when it comes to interacting with customers. Since the majority of your customers will have common questions, you can design a chatbot that can answer redundant questions.

You don't have to employ additional customer service professionals or make your customers wait in a queue. Chatbots are saving businesses time and money, thanks to Machine Learning.

Spam filtering

Spam filtering is a simple yet powerful application of Machine Learning. It is the reason why Gmail or Outlook can filter out spam emails for you with high accuracy.

Spam filtering systems are also built to learn from experience. This model, also called reinforcement learning, can understand your preferences better when you mark an email as spam.

We now have cleaner inboxes, thanks to Machine Learning.

Language translation

What would we do without Google Translate? Machine learning-based language translation engines save businesses millions every year.

Before machine learning, translation services were entirely human-powered. Thanks to machine learning, you can translate large data sets to any language in a matter of mere minutes.

Tools and Frameworks

Machine learning and deep learning are accomplished by using different libraries and frameworks. Though other languages have their own tools, Python is usually the preferred language for machine learning.

Here are a few Python frameworks you can use to build your next machine learning or deep learning product.

• Scikit-learn — Popular for machine learning problems. Great community support. Not suitable for complex deep learning models.
• Tensorflow — Most popular deep learning framework. Built by Google. Supports all complex deep learning models like CNNs and RNNs
• PyTorch — Built by Facebook, scalable, and offers high performance.

I recently wrote a blog post on popular deep learning frameworks if you are interested.

Conclusion

Machine learning has the potential to transform every industry. From voice assistants to self-driving cars, the applications of machine learning are all around us today. It can help you understand your customers better and make smarter decisions with data.

I hope this article helped you get a good grasp of machine learning and deep learning concepts. If you are fascinated by machine learning as much as I am, check out the Machine Learning course on Coursera by Prof. Andrew Ng.

I regularly write about Machine Learning, Cyber Security, and DevOps. You can signup for my weekly newsletter here.

Guides to help you work remotely seem to have swept through the Internet these days.

Do this, avoid that, stay productive, and all those run-of-the-mill tips we’ve already tried out.

So instead of talking about how your remote team needs to schedule out their day effectively or clean their desk, here I am focusing on the hands-on tips you can apply to manage your software development team while working remotely.

First, we need to understand the exact meaning of “remote teams”.

This will allow you to clearly see that having even one individual who’s working separately means you should improve the way in which you manage your team and the process they use for remote team collaboration and task execution.

What are remote teams really?

Today, millions of companies are faced with remote work situations in one form or another. Whether they’re fully-distributed organizations, have a couple of employees working from another part of the world, or just regularly work with external collaborators.

The first thing that comes to your mind when you think of remote teams is something like: different people working from all parts of the world and distinct time zones on a single project and having the same general goals.

In reality, there are many remote teams that have employees in a single country or even in one city. It’s just that everyone works from their own home, without having to go to the office. ? This saves on costs while managing remote teams.

Source

But many companies (software development included) have offices in multiple countries. When your US team members talk to their colleagues from the UK, they’re essentially collaborating remotely. So remote team communication is a must in these cases even if everyone is in the office.

This being said, whether work is done from an office or not is not necessarily a defining factor for remote teams. The problems you could experience lie solely within the communication and work processes.

Best practices for managing remote software development teams across multiple time zones

Since you’re probably used to all the “do this to be productive” rants, I’ll try to tell you what you might not know.

Hire the right people for your remote teams

People are the heart of any team.

So if you hire the right professionals [and humans] for your team, you’re halfway to success.

On the hiring and interviewing process, here are some of the best tips from Shannon Hogue, Global Head of Solutions Engineering, @Karat:

“I always tell hiring managers to start at the review and work back to determine which core competencies should be listed in a job description. Then, to keep things standard across a global network of Interview Engineers, we put those competencies into structured scoring rubrics for each interview.

Here are 3 quick steps for building a structured rubric that can help keep everyone on the same page, be it for hiring or managing:

Identify what competencies are both relevant and important to assess.

For each competency, list observable behavior and results as checkboxes (select all) and/or radio buttons (choose one).

Write down an “algorithm” to help interviewers summarize a completed rubric into a single conclusion.

For example, if Technical Communication is a relevant competency you might list it on the rubric with a specific scale.”

Here’s what Shannon’s example could look like:

Beyond any hiring tip, effective remote work also imposes a question on whether your office workers will adapt to the new lifestyle.

If you’re switching from an office team to a distributed one or even if you want to hire someone who hasn’t worked remotely before, you need to guarantee they’ll fit in the team and work efficiently in your remote team even before day #1.

For software developers the demand is so high that you’ll often bump into this problem:

How do I make sure that who I’m hiring is the perfect fit within our team when they haven’t worked remotely at all? ?

Perhaps tech professionals are some of the easiest to assess beforehand. Check out any of their side projects, if they own a business or do freelancing, and even look at their online presence.

A developer who’s only been putting work for their official job and has no GitHub repositories and projects to boast is clearly not going to be someone you’ll trust right away.

Trust and accountability are the 2 main attributes to consider beyond any hard skills.

These two character traits (which we often ignore because we’re too focused on business results) can predict whether that person will fit within your team culture. And, even more importantly, if they’re willing to stay with your company for many years to come and dedicate themselves to your project.

From then on, managing remote teams is also a matter of how you handle their training.

Onboarding and training

The trial period all HR experts recommend exists for a good reason. It allows you to literally SEE how they work, collaborate, and get along with the rest of the team.

Many managers make the mistake of hiring a developer, letting them start the trial weeks, but not monitoring what they’re actually doing.

Don’t assume that someone who seems skilled and experienced will deliver the same commitment and quality of work to you too. May I say this is the best and only time to be a micromanager and literally oversee all of their actions.

But do offer your help within the first days by making sure they have all resources needed and making the appropriate introductions to your team.

Get them involved in the code writing process for your project as soon as possible so you can get a better feel of how they conduct their work. I’ll also advise you to try a pair programming session during the hiring process too. More on this procedure later in this guide.

Prepare the right work methods

This is largely the manager’s decision. Team feedback is only valid when everyone knows the relevant best practices and benefits of each work method. This doesn’t mean you can't get their input on the methods they’d prefer to use. However, letting them take care of the decision process will only give rise to conflicts and postpone the choice for the time being since there simply will be too many opinions for you to sort out.

“While you do not want to micromanage a remote team, you certainly want to set up clear minimum administrative processes. For a previous remote team I had to manage, this included setting-up very precisely the infamous JIRA workflow.

While it is good to leave a remote team some freedom, work also needs to be clearly organized, so there should be a few processes that have very precise descriptions. In development, the most important of such processes are issues management, and also the build process. This should be described in detail, and followed strictly.

To make sure key processes are respected, there should be set points when work needs to stop until the process is followed. As an example, I gave strict orders to my business team not to look at any incident that is not documented.” - Nicolas de Mauroy, CEO @Open Lowcode

But how close should supervision really be?

Surprisingly – not that in depth.

Keep your devs under your radar only enough to guarantee that all processes run smoothly and you’re able to maintain a trust both ways. Yes, 50% of data breaches across all industries are caused by insiders, but that doesn’t mean you must force everyone to track their time or record their screens.

Developers should really only have to track their time in 2 instances:

1. They/you really want to improve your work processes.
2. They’re getting paid by the hour.

Your role as a manager goes beyond the person who is seemingly in charge of everything. You’re a liaison. That key link between one team member and another, helping your development team collaborate with operations, marketing, design, customer support, and sales while also ensuring all team members are happy and their needs are met.

I’m super disappointed to tell you that only 35% of managers are engaged with their work. How is this going to motivate someone else?

Employees who are supervised by highly-engaged managers are in turn going to be better and happier performers themselves. This will boost your employee retention rates and create that long-lasting company-worker bond most companies can never attain.

This takes me to the importance of knowing when and how to communicate. Both ways.

Craft your remote team collaboration plan

Collaboration goes hand-in-hand with your work method and how you manage tasks. It’s the little things like crafting clear task descriptions and expectations that add up to distinguish a positive collaboration experience from a chaotic one.

Tinjo Thomas, Design Technologist @Coredes Interactive also recommends the following two tweaks you can make:

“1. Always set a due date for each task even though your developers are experts and can make estimates themselves.

2. If you are giving instructions to only one or two people, don't send the message to the whole group. Reach out to every individual in private. People spend a lot of time reading unnecessary conversations on channels.”

On meetings

Meetings are honestly a very controversial topic. Managers love to call meetings. Devs, though, hate most of them but are afraid to voice their thoughts.

To keep meetings relevant, here are some actionable points to keep in mind:

“On a more macro-level, knowledge sharing can happen through a weekly team meeting with a Q&A via video whereby the members of the team can share what they learned from the codebase with each other as well as ask questions. In terms of knowledge sharing through team meetings - you can have several types of meetings.

The overall idea for these is to encourage collaboration in an effort to turn explicit knowledge into tacit knowledge. So you can have brainstorming sessions or meetings geared more towards lessons learned (this can be in the form of a demo or presentation). All done entirely remotely.” - Emil Hajric, CEO @Helpjuice

One huge mistake first-time remote team managers make is filling up entire days with meetings:

“First-time remote team managers need to be quite aware of the differences between collaborative work [like Scrum meetings and software architecture design] and individual focus work [like coding]. It is important to schedule time and ensure everyone can contribute to the collaborative session, but then leave your professionals alone to do what they were hired to do, write great software.” - Pedro Henriques, Co-Founder & CEO @BRIDGE IN

You’ll want to always remember to press that record button during meetings. We’re not necessarily fans of paper trails, but you’ll need them to avoid bothering your team with issues that have already been discussed:

“You should be recording and saving absolutely everything from remote team meetings and strategy sessions. While working remotely, we've noticed a huge uptick in productivity when managers and team members can refer directly to meetings instead of having to play phone tag or email back and forth for simple information. It's a huge boon to workflow across the board and should really become the new normal with the increase in remote team management.” - Alexander M. Kehoe, Co-Founder and Operations Director @Caveni

Keeping up-to-date with all changes is even more important when your team’s distributed. But remote teams have different approaches to how they make sure they don’t just communicate, but also apply and consider every opinion.

Here’s where the real-time vs asynchronous communication battle comes in. Everything’s already been said about this. So the conclusion is:

There’s a right time for each type of communication. A predisposition for certain types of tasks will also make your remote team more likely to go for one method of communication over the other.

Just like the video vs written communication issue.

The Voro team, for instance, has used their office and remote communication tests to conclude that written collaboration worked best for them:

“My #1 tip for managing a remote team is to default to written communication rather than video calls. This forces you to clarify your thinking and communicate succinctly. When we all worked in the same office, it was easy to walk over to someone’s desk to talk through a problem. It would waste a great deal of time to replicate that with a scheduled video call.

Since we are 100% remote, more of our communication has been written, and we try to memorialize most of that in internal documents, so we continue to move fast and share institutional knowledge seamlessly.” - Tomas Hoyos, CEO @Voro

Invest more time in one-on-ones

With one-on-ones, you’re focusing more on sharing the status of specific tasks and individual activities, while every single member on your team gets to make their own suggestions. One-on-ones are commonly held between one team leader and the other members at a time.

Having these twice a month is your best bet to make sure everything gets covered. Holding them weekly is too often as you won’t have time to focus on your other tasks because you’re too busy with meetings.

These one-on-one meetings are also a good opportunity for you to hold reviews and updates on the OKRs. To facilitate the feedback and ideation process, Charles Ahmadzadeh, CTO @Bunch uses checklists during these meetings:

“I like to use checklists with my team. I'll ask each team member to create a checklist each day of what needs to be done before ending the day and before submitting their work. We review these checklists in 1:1s to spot patterns.

I mostly use this to help others around me grow or keep myself accountable to the feedback I receive from the team.

The good thing about them is that they work no matter how senior you are (even astronauts live by checklists). They’re easy to share in 1:1, even if your team is remote, and very simple to use, as long as you’re committed to improving yourself.”

NOTE ON OBJECTIVES AND KEY RESULTS: Team leaders can establish these at a team and individual level by also taking into account suggestions from developers.

For instance, each department or team can have specific targets: to release a feature on time, avoid more than 2 major bugs after a release, keep the error rate low, etc. Individually, each member should take care of one release so that every single team member will know how to handle them.

Here’s an actionable idea: Use TrackJS [or other error tracking tool for your programming language]. Every member can choose a top error and fix it. This allows members to increase their accountability and learn new things to avoid freezing their skills.

Pair programming finally getting the attention it deserves

Now is also the best time to experiment with pair programming. This practice allows two developers to work simultaneously, often on the same tasks. While this is usually done from the same computer, you can switch it up a bit and make use of tools like TeamViewer or screen sharing.

Pair programming also helps distributed teams improve the quality of their code, tighten bonds between colleagues, transfer information and know-how from one dev to another, increase their own accountability, and speed up the entire development process.

Does this make you feel like you’ve been missing out on all its benefits? ? Just keep in mind some best practices if you want to get started with using the pair programming practice on a regular basis.

By using common sense, you probably won’t have both developers working on the same thing for 8 hours straight. Instead, distribute tasks evenly and allot a specific time slot for them to actually work together. Dealing with multiple time zones? Pair programmers within similar work schedules.

Communicate beyond work with your remote teams

We’re all humans. So we can’t work, work, work all the time. How about you implement some activities for people to destress twice a week as part of your remote team management process?

Playing board games online. Having a #watercooler channel on Slack. Finding some creative online team building activities. These are all ideas to help your remote teams unwind and get their mind off anything that’s stressing them out.

Pedro Henriques also shared his thoughts on the importance of implementing this type of downtime while working remotely:

“Remote teams need to deliberately schedule slack time and create informal virtual watercooler moments. In the office, the watercooler or coffee machine is often the place for spontaneous discussions about various topics ranging from a nasty software bug to vent about office politics or even troubles in personal life. These discussions are not superfluous. They’re absolutely critical for team cohesion. Therefore managers should actively promote them, but make sure not to attend.”

Choose the right tools: The basics will do, there are no magical solutions

I’ve seen so many “best tools for remote work” lists the Internet could really crash for good.

Nah, but really, stop looking for the best apps and miraculous software to somehow save your remote teams.

We already know everyone is using Slack and Zoom to collaborate and the ones who don’t use these are probably doing so because of small issues they had or costs they wanted to lower.

For instance, from all apps I’ve tested for this purpose Google Meet was the fastest and most accurate one but guess what? My clients are using Zoom already. No room to impose another tool.

The key point is not to waste weeks trying to find the right tools for your team. Others have already done this. There are thousands of options out there. All of them are copying features from each other so you end up with the same tool in dozens of versions.

So here’s your stack:

Jira - Slack - Zoom - GitHub - InVision - a bug tracking tool - every developer’s code editor

Test these [preferably the free versions first] and only look for alternatives if you have huge issues that are stilting your workflow. My two cents.

Also, some wise words from Tinjo Thomas:

“Don't try to save money on bug tracking or team management tools. You will know why it’s important when things don’t get done as you expected.”

Know a remote team manager who could use these tips? Share this remote team management article with your network to keep improving remote work processes.

Remote work is rapidly growing in all industries. Some professionals might try to push away this new way of working, seeing it as simply a current necessity. They might not think it's fit for a product manager who’s constantly managing team members, strategies, client and partner communication, and upcoming challenges.

But let me tell you this:

Product management can be even more effective when done remotely.

No need to fear going for this career path.

I’ve put together this detailed guide to help you understand the challenges of remote work and its implication on your product management career.

First, let's have a look at a remote product manager’s core duties.

What it means to to be a remote product manager

I’ll just say this from the start:

There’s not much of a difference between what a remote product manager does when compared to someone who works from the office.

In fact, you’re probably already doing part of your work remotely. Like conducting user interviews or holding meetings with your stakeholders.

Your role in remote product management

So what does a remote product manager even do?

Different companies and products have specific needs. Your daily activities as a product manager or owner can be similar though. Remote PMs have the exact same roles as their office-based counterparts.

Here are some of the duties a product manager has:

• Lead the development of the product and its strategy across multiple lifecycles
• Discover user requirements through user interviews
• Develop the positioning and vision of a product
• Use a variety of tools to produce wireframes and mockups, gather feedback, and deliver results
• Establish clear timelines and feedback patterns
• Define quantitative and qualitative metrics and use these to evaluate the success of the product and review delivered work to ensure alignment with the specifications
• Build actionable user stories
• Create and manage the product roadmap
• Maintain consistent client and stakeholder communication
• Partner with other teams to ensure a unified product development and delivery process
• Lead the product team and take full responsibility for its actions
• Create new feature announcements and content

Who hires remote product managers?

To find a new remote job and make the first step towards this ideal lifestyle, you can simply look under the Product category of these remote-exclusive job websites:

• Dynamite Jobs
• DailyRemote
• Working Nomads
• Remote Age
• Remote Global
• Remoters
• Jobspresso
• NODESK
• letsworkremotely

Good news is that more and more companies are starting to consider switching to distributed teams and even accepting remote workers for highly skilled professionals. If you need an overall look at some of the companies who are hiring remote product managers, here’s a list to start with:

• Buffer
• Canva
• MailerLite
• Close.io
• Convergys
• ConvertKit
• Hotjar
• MeetEdgar
• Pearson
• Dell
• DigitalOcean
• Glassdoor
• Pluralsight
• Toptal
• VMware
• Zapier
• Apple
• Automattic

Keep an eye on their job boards to see when a new opportunity pops up.

Note: You can always just ask your current employer to let you work remotely or reach out to companies you’d love to work for and inquire into any available positions.

Why working remotely might not be right for your product management career

Just like the skills of an in-office and remote product management expert are similar, there are a couple of personality traits and habits that will influence whether or not you’re the right fit for working remotely.

To get it out of the way, it’s safe to say that bad communicators will never make it as remote employees. These are those people who can’t take feedback, always have to contradict other team members, and just don’t want to answer your inquiries on time.

Product management is fast-paced. ? Especially in small teams who are commonly the ones looking for remote members anyway. So communication needs to be done in detail and accurately even when you’re not face-to-face with the rest of the team.

There’s no time to nudge people into sharing their thoughts or asking questions when they don’t know how to move forward with a task. Even more so, the product manager should be the one to tie together all team, user, client, and other stakeholder communications.

That’s why most remote product management jobs start with “X years of experience in a cross-functional product design or product management role”. Companies want their product managers to be dependable. Sometimes even more than what they expect from the rest of their team since they’re literally handing over the product to you.

If you’re a constant slacker who’d rather scroll through Reddit for hours than create one more ticket, you’re better off somewhere else.

What are the skills you’ll need to land a remote product management job

A product manager in general needs to have some of the most varied soft and hard skills in a team. Honestly, besides exceptionally good communication and organization skills, the traits and abilities you need to develop are roughly the same as for any office job.

I had a look at 100+ remote product manager jobs on Glassdoor so you don’t have to assume what the top skills for such professionals are. Next are the results that prove my point. ?

Here are some of the most commonly mentioned skills that employers are looking for from their next remote product manager:

• Strong leadership skills
• Organization and prioritization capabilities
• Critical thinking
• Excellent communication and interpersonal skills
• Strong client management abilities
• Ability to manage multiple, simultaneous projects
• Time management and budgeting skills
• Command of diverse product development frameworks, strategies, and/or rapid prototyping solutions
• Ability to troubleshoot customer issues and create detailed bug reports
• Ability to work autonomously
• Passion for working cross-functionally
• Problem-solving skills
• Strong technical understanding of how software products are built
• Ability to collect and structure qualitative and quantitative research that will be used for making product and design decisions
• A clear understanding of key metrics and ways of measuring a product’s success

All in all, the requirements depend on the company you apply to. Some will prefer a strong communicator who is able to work cross-functionally and bring the entire team together. Other employers will have specific needs such as programming language knowledge or stronger experience when it comes to user interviews or focus on a specific stage of a product’s life cycle.

What you’ll need above any of the above skills is product sense. This means you’ll first have to become a subject matter expert and learn all the ins and outs of the product. You’ll then own the entire creative process around generating new ideas, spotting challenges, and creating the whole roadmap along with doing user research, keeping track of metrics, and prioritizing tickets.

Simply, you need a complete product-oriented skillset along with dependable traits that will allow your employer to trust you with their product’s evolution and fixing potential problems.

Where to start your remote product management career preparation

There’s no training in particular that you need to go through separate from your usual product management courses.

However, before jumping into this entirely new work style, I recommend you test it out for a couple of weeks or months. Try a side project or get a part-time job that will have you interact with clients and other team members through multiple time zones. Having this kind of beforehand experience will show you if you actually like collaborating this way, if remote work is suited for you, and where you need to improve.

You might not like using multiple tools to maintain communication or maybe you’re just someone who only feels productive in an office environment. For tiny problems like the latter, try to find an actionable solution. In this case, go to a coworking space daily or set up a fully equipped work desk.

If the issues are huge [like when you’re not productive at all without supervision], there’s really nothing you can do.

If you’re at the beginning of your PM career, being ready for remote work is the least of your worries. You’ll first need to develop and grow your product management skills overall.

Some of these skills include learning how to conduct user research and market analysis, knowing what goes into a product roadmap, understanding how PM frameworks can be used within different types of teams, learning how to set and monitor key metrics, and so many more product-focused skills and roles you’ll put to use for real products.

By far the biggest struggle new PMs always have is worrying about their interview process.

What will I say?

What if I don’t know the answer to a question?

I’m not ready for this job.

All natural concerns for any product manager newbie. There’s so much help out there though. ?

I’m a huge networking fan so the best tip I’d have for you is to connect with experienced product managers who are willing to coach and prepare you for your next interview.

If you’re the shy type, you can always opt for classic LinkedIn messaging instead of face-to-face meetings but bear in mind you’ll have to get over your fears to nail the interview. ?

Remote product management best practices

So you’ve landed a new job or you just want to prepare yourself mentally for what’s to come? I’ve put together my 6 best tips I’ve acquired throughout the years from my own experience and talking to other professionals:

Maintain a regular schedule

One of the top perks of remote work is flexibility to work whenever you want to. Honestly though, as a product manager you might have to mold your schedule according to when the rest of the team is online.

Postponing work [and implicitly communication] can cause serious gaps in productivity. If you don’t know when you have to work on your tasks, when it’s time to dedicate yourself to prioritizing other colleagues’ duties, and when you can still fit in time for feedback and meetings, you’ll end up postponing everything indefinitely when you’re really supposed to be one of the faster responders in the team.

As a PM, others look up to you and expect your input and instructions at all times. So compared to the asynchronous communication that remote companies are used to, sending feedback and holding video conferences in real-time works better for product managers and their teammates.

This takes me to the importance of establishing clear communication patterns and methodologies.

Communicate

You already know the story: communication rules when it comes to remote work. Yet, in this kind of work situation, one-on-one meetings are more insightful than ever. They allow product managers to talk to every single member of a team individually, get feedback, and improve not just their product, but also the employee-company relationship.

Beyond this, you need to understand that working remotely takes extra effort for maintaining those friendly work relations you would in real life.

Managers have a top duty here: to create strong bonds that will eventually build up employee retention.

No ideas? Turn to your team. Hold special opportunities for non-work related activities like get-togethers or just a weekly one-on-one meeting to allow employees to get to know each other better, learn about their hobbies, and make a new friend.

Turn to video tools to bridge the communication gap

Your basic Slack back-and-forth messages or email exchanges create huge information loopholes. They don’t give enough room for clarifying any details and you might end up with results that are totally different from what you’ve expected.

Video, on the other hand, fully replaces your face-to-face office meetings. All remote fun aside, in-person meetings are still an essential part of work for humans as they allow your team members to understand that there are other people who depend on their performance and it’s not just them working from an empty office.

This, in turn, creates accountability, making the entire collaboration process much more effective.

Plus, screen sharing will save the day every single time.

Establish clear review patterns

There’s no such thing as working aimlessly. You need goals and set performance review methods to assess whether the work you and your team puts into a project or product is efficient and spot potential bottlenecks.

To keep everyone involved in this review process, set up a defined timeline for your review tasks and meetings. For instance, decide when and how to hold your daily stand-up meetings. Working remotely you have lots of possibilities for every single review process.

For the stand-ups you can opt for video conferences or use a Slack bot to automate everything and save time since team members can simply write down what they worked on, what they’re taking care of on a given day, and their potential challenges.

The review workflow doesn’t just end here as you’ll probably have to take over and see how and who can help a person with their issues so the product development process can run smoothly.

Address risks ahead of time

While strong communication is a common trait both on-site and distributed teams need to develop, what remote product managers need more than anything are plans. Particularly a highly-detailed action plan for tackling risks before panic installs.

I’m talking here about a common document any team member will access to read and find out how they can manage their own crisis.

Keep your whole team on board

Working remotely is a collective effort. As the person who’s held responsible for any success and failure of your colleagues, you’re in charge of cultivating a desire for remote success within the team.

Here’s the list of everything your team needs to understand and work on before you jump into the world of fully-distributed companies:

• The benefits of remote work
• Communication guidelines
• Risk management techniques
• The importance of feedback and staying connected
• Staying accountable for one’s work
• Get involved in the teams’ overall growth by supporting its cohesion and moving collaboration processes forward
• Developing traits and skills such as discipline, empathy, dependability, and self-organization [in other words, constantly developing themselves on a personal and professional level]

Key takeaways

So yes! You can work remotely as a product manager and be just as effective at your work. No performance limitations here.

Product managers still have the same duties and roles when working from home or an exotic beach in the middle of nowhere.

Daily work is quite similar too but your quality of life is highly improved. Here’s what a day in your life as a remote product manager might look like:

• Take care of urgent tasks or team/client inquiries
• Stay updated with any industry or market changes
• Do some networking ?
• Stand-up meeting time! ?
• Work on the product roadmap
• Take a well-deserved lunch break ?
• Answer some more emails
• Respond to tickets
• Client meeting
• One-on-meeting with one of your teammates
• Sprint retrospective! ?

Do keep in mind that product managers have some of the most diverse days with a constant flux of new challenges and opportunities that need to be covered.

Already a happy remote worker? Share your best tips with fellow product managers or people who are considering this career but have been hesitant thinking it’s not suited for the remote lifestyle.

If you want to get more technical with your product management skills, being able to work with flowchart or diagram creator apps is surely on your list.

The following guide aims to save you hours of time you’d otherwise spend researching the best diagramming solution for your project while at the same time perfecting the design of your flowcharts.

As a general rule, a flowchart or diagram is used to communicate requirements, processes, and workflows in a logical way so complex concepts will be a little less complicated.

In product management, workflows are commonly used to describe:

• User flows
• Processes and other systems involved in them
• Dependencies between systems and inputs, outputs, or other conditions

I’ve tested and reviewed several tools for creating flowcharts and workflows over the past few years. Here, I've picked 5 that you must try out to describe your product’s funnels and flows.

But first…

Why are diagrams so powerful in product management?

While the whole idea of using flowcharts and diagrams might be overlooked or seem like it’s an unnecessary step, there are several benefits to using diagrams in PM:

• It simplifies all processes
• It helps you spot issues or weak points at a glance
• It allows you to find any duplicate parts of a process
• It establishes clear funnels
• It supports your Quality Assurance team during the creation of test scenarios
• It acts as a roadmap for software architecture

So how do you choose the best diagramming software?

Creating any kind of diagram is a fairly easy process. Building a successful one, though, takes a bit more research and time.

That’s why you need to choose a tool that will help you save hours of work while also giving you the predefined requirements you’ll need to build accurate diagrams and keep the process fun.

The key aspects to pay attention to when choosing a flowchart creator software solution are:

• Availability of ready-made templates
• Lots of choices for shapes and arrows to work with
• Extra tools or integrations
• Exporting options
• Strong collaboration features
• Ease of use from the beginning

To make it easier for you to select your next tool for building diagrams, I’ve highlighted all of these aspects for every individual solution across the following reviews.

Next up are my favorite free flowchart creator and workflow diagram app picks you need to take into consideration.

5 free flowchart creator and workflow diagram tools

Lucidchart

Lucidchart should be your top-of-mind solution for creating customer experience maps and systems diagrams in particular. From the very beginning, the tool makes it easy for product managers to select the type of flowcharts they want to create. Matter of fact, the onboarding process and resources available online make it a tool with a fast learning curve.

From the very beginning, you’ll get all possible templates needed for you to create product strategies, create roadmaps and product flows, and even pitch your ideas to stakeholders. With ready-made templates and literally thousands of shapes and arrows to choose from, there are endless opportunities for product managers to create their materials in no time.

Also, if you’re like me and like to add a few too many colors, this diagram app comes with a bunch of theme options to help you nail the design of your creations. Bonus points for customization here from non-designers.

The reason I’ve placed Lucidchart first on this list is that it’s a complete flowchart creator tool. Collaboration options are some of the strongest with comments that can be left on charts just like you would in Google Docs, slides that can be used to present your diagrams, and even sharing and exporting options.

If you’d like to take it all one step further, you can choose from dozens of integrations with tools you might already be using like Slack, GitHub, or Salesforce.

You can also check out my video tutorial on using the tool so you won’t have to find your way around Lucidchart yourself.

Pros

• Free plan available
• Easy to learn
• Lots of templates and elements to choose from
• Strong collaboration features

Cons

• Limited space for free accounts
• No desktop app

Draw.io

Draw.io is a top choice for many PMs since the tool’s free, so you might have already been using it for several other business processes. Since the tool belongs to Google the interface is similar to other Google Apps like Docs and Slides that you’re probably working with anyway.

Compared to Lucidchart, Draw.io might be harder to use for non-designers since there are no theme colors to choose from if you want to make your diagrams eye-appealing.

Whenever you want to create a new diagram, you’ll get to choose from a series of templates ordered by their structure. There are no specifics for product management.

The flowchart tool does save itself through lots of elements you can use on your workspace. I advise you to use the search bar to find a specific item or element faster.

Since the tool is so simple that even a child could use it, Draw.io is missing the advanced functionalities and collaboration features that would otherwise allow you to communicate with your team directly on the document. To do this, you’ll need to integrate it with a tool like Confluence or Quip.

Pros

• Free to use
• Clear interface which makes it easy to get accustomed to

Cons

• Limited templates
• No collaboration options
• No mobile apps
• Few integrations

Creately

Creately is only a free workflow diagram app if you can accept the fact that all of your design will be public and you’re limited to 5 documents. Team plans start at $12 which is a fairly decent price considering you’re getting all the features with it.

I specifically found their onboarding process handy since it introduces you to the tool so you won’t start and have no idea what to do next.

In many ways, the tool is similar to Lucidchart. You’ve got lots of templates to choose from, all of which are ordered by their purpose. Then you’ve got your elements which are some of the most beautiful I’ve seen, along with other styles and theme options to help product managers who aren’t that skilled at design too.

One thing people struggle with while using Lucidchart is file organization, a feature that Creately nails by turning their tool into an alternate file storage app. The tool also eases the process of working with several elements by integrating Google search so you can find images to use without leaving the app.

In terms of collaboration, Creately works similarly to a prototyping tool, allowing people to leave comments on the exact element they have feedback to offer on. Collaboration is done in real-time via the online or desktop version of the app.

Pros

• Lots of templates to pick from
• Theme options
• Communication options
• File organization option
• Works offline too
• Easy to learn

Cons

• The free option only allows you to create public content
• Some features are still under development but will be released soon

Whimsical

Whimsical is a user-friendly visual communication tool that’s commonly used to create wireframes but has separate options for putting together flowcharts, mind maps, and sticky notes.

While the tool is highly visual, there aren’t that many template options to choose from. This is because the app is centered around creating basic wireframes and flowcharts for internal use only. Shapes and connectors are also limited, but there are hundreds of icons to go for if you want to add some extra color to a mind map or flowchart.

On to the benefits of using the tool: collaborating on each project takes fewer than two steps, with comments being placed on every single element you want to leave immediate feedback on. All work is easy to share, export, and even embed.

Ever been annoyed by losing your past versions for a product development flowchart you were supposed to show to your stakeholders? Whimsical is one of the few tools that has a fully-featured file versioning option that records every single change you’re making on a chart so you can restore better versions.

Pros

• Strong design options
• Easy to learn
• Sharing and exporting options
• Lots of icons to add to your creation
• File versioning
• Free version available

Cons

• Limited template options

Canva

Canva is not really a common option since it’s usually used by marketing and social media teams who need highly-visual content to display publicly. If you’re also looking to create a flowchart to present on your social networks, in your pitch deck, or to any other stakeholders, it’s definitely worth giving it a try.

Not only is it easy to use, but the fact that it’s a general app instead of being tailored only to building diagrams also means it has thousands of elements and icons you can choose from. Illustrations, arrows of all kinds, customizable charts, you name it. Even videos.

As for the sharing options, they’re top-notch. You can export your content into any file type you want, resize your workspace to share it on multiple platforms, and use the presentation mode, complete with notes for presenters.

Once you invite your team into the tool, you’ll be able to leave comments on your designs to keep everyone on the same page.

Pros

• Free option
• Extremely easy to use
• Versatile
• Focused on great design
• Lots and lots of options for elements
• Collaboration options

Cons

• Limited template options for product management

Haven’t decided yet?

Start by creating a list of your own requirements. Are you in need of strong templates so you don’t have to build everything from scratch? Or maybe you can give up on lots of elements as long as collaboration options are on point.

Based on your own needs and goals, go over the above list to pick an option that works best for you and give it a try. Each option has its own unique features that distinguish it from the others:

• Lucidchart - lots of template options for PM
• Draw.io - super easy to use
• Creately - most features in one tool
• Whimsical - clear interface for internal use
• Canva - focused on design

If you have any other tips on helping product managers choose their next flowchart creator workflow diagram app, let me know.

Recently, Product Management (PM) jobs have become one of the most popular career options for graduates from top MBA schools, following consulting and finance. At the heart of Silicon Valley, the question I get asked most often has also changed from “How can I get into Stanford GSB?” to “How can I land a PM job like you?”

Many people chase after a PM career because a PM is often regarded as the Product CEO. Even thought the title seems pretty eye-catchy, the reality is that PMs have no authority over anybody. Your everyday routine will be spent attending an average of 8 meetings, writing documents, and putting out fires.

Another brutal fact is that recruiting for PM jobs with no PM background is a lengthy and challenging process. You will probably not hear back from most of the companies you apply for and are likely to receive more rejections than ever.

If you keep trying, though, I am confident that you will eventually land on a PM job. However, your first job might not be a product you feel so passionate about.

If you are still interested in a PM career, hold tight, this fun ride is about to start. The rest of the post will answer the following two questions about PM recruiting:

1. How should you prepare for a product manager interview in a few weeks?
2. What was the secret sauce behind my successful career switch from finance to PM?

How to prepare for a product manager interview in a few weeks

Most PM interviews are composed of 5 types of questions: product design, strategy, analytical, technical and behavioral. I have found that the majority of candidates without a PM background need the most work on product design questions.

On top of that, if you only have a business background like I do, technical questions will probably scare you the most. If you are an engineer, strategy questions will look like a monster. The good news is that regardless of your background, you can prepare for most PM interviews. It takes a lot of effort, but these skills can surely be learned.

If you only have a few weeks before your first PM interview, here are a few must-dos:

• Get a copy of the PM interview bible Cracking the PM Interview ASAP. Focus on Chapter 13 (Estimation Questions), Chapter 14 (Product Questions), and Chapter 15 (Case Questions). I have also read Decode and Conquer and 164 Actual Questions and Answers. They helped me prepare for a diverse set of questions, but I didn’t find them as relevant as the first book. If you don’t have much time, I would recommend just go for the bible.
• Study 3–5 products that you like and be ready to answer the two most famous PM interview questions “What is your favorite product?” and “How can you improve it”? If you have time, I would strongly recommend going through the exercise of writing down a product goal, users, main use cases, product strategy, personal story, competitors or substitutes, key metrics, and moonshot ideas for each product. This exercise will significantly improve your product sense in a very short amount of time. You will be surprised by how your business or engineering brain can just operate like a PM.
• Get yourself on StellarPeers founded by Malena Mesarina. It's an amazing PM interview prep forum that gives you sample answers to all types of PM interview questions. It is also free. Read through sample answers and summarize your own answer frameworks for different question types.
• For technical questions, I would recommend doing lots of wikipedia searches, watching Youtube videos about software engineer interviews, reading this open-sourced system design primer, and reading through the two free lessons on Grokking the System Design Interview. It is more and more rare to get coding questions in PM interviews but system design questions are increasingly popular. If you have more time, taking CS classes online is the best way to catch up on technical stuff.
• Find a mock interview partner and do as many mock interviews as you can. StellarPeers is also a good place to find mock interview partners but it’s hard to tell whether your partner’s level is gonna be close to yours. A genuine warning for folks who plan to read through all the materials and only start mock interviews when you feel ready: trust me – you will never be fully ready. It is like learning to swim. Learn from mock interviews and get a sense of how to tackle super ambiguous interviews on the fly. You will save way more time by jumping into mock interviews ASAP.

Image credit: Wikimedia

What was the secret sauce behind my successful career switch from finance to PM?

In 2017, I left my banking job in Hong Kong to pursue my MBA at Stanford GSB. At the beginning of my MBA2 year, I received a full-time product manager offer in the Bay Area. Many friends have asked me how I did it, especially without a technical background. Let me share my secret sauces here. You should tell me if they are secretive at all.

First, you need to know what you want.

After I left banking, I spent 3 months interning as a chief of staff at a Chinese startup. This experience allowed me to get a good sense of different operating roles and I found myself naturally attracted to product management. As a result, instead of putting eggs in different baskets like many of my MBA classmates, my recruiting was laser-focused on PM.

Image credit: Diocesecpa

Second, I am always excited about learning something new.

PM interview questions spread across so many disciplines, engineering, business, design, analytics that they sometimes even seem intimidating. A learning mindset is particularly effective in helping you power through PM recruiting. If you see preparation for PM interviews as an opportunity to learn new knowledge and skills, you are more likely to succeed.

For example, I didn’t know how to code or what an API was when I left banking. But I got lots of energy from the sheer fact that I could pick up useful technical skills while recruiting for my next job. I signed myself up for entry-level CS classes, e.g. programing abstracts, web applications, machine learning and deep learning, and coded my own coaching website.

Third, don’t ask for permission. Make yourself a PM.

An irony about PM recruiting is that most PM openings require candidates that have PM work experience. I empathize with these companies because due to the nature of PM jobs, direct PM work experience is the ideal indicator for a candidate’s likelihood of job success.

The reality is that seasoned PMs are under-supplied, so Career Switchers, you do get a chance. The key here is to build up your PM experience without a full-time PM job. There are two good ways, i.e. product study and side projects.

PMs live and breath products. Put on your PM hat by simply paying attention to products around you, whether they are software, hardware, or non-technical. It is actually quite fun to ponder about questions like “Why are Facebook’s login pages not designed for logging in but signing up?” and “How can Live Photo take photos before you press the shutter button?” and “What made Typeform such a success despite scary competitors like SurveyMonkey?”.

Working on side projects or taking on part-time PM jobs are also great ways to build your PM credibility.

• If you have a product idea, fantastic. Get yourself out there to start interviewing users, identifying pain points, coming up with product requirements and mock-ups. If you can convince an engineer to build a prototype together, that’s perfect. Even if not, it is still a valuable experience that you can talk about in your interviews.
• If you are still at school, do you know that you can get part-time PM jobs from early stage startups more easily? Most pre-seed/seed startups can’t afford a full-time PM. If you don’t mind volunteering as a PM for a few months, many startups would say yes.
• If you have a full-time job, your best shot is to ask for a project on which you can function as a PM or work closely with a PM.

Fourth, respect the hard work required for PM interview preparation.

Most people I knew who successfully switched into PM did lots of good interview preparation work. The reality is that it takes time to catch up on what you didn’t know, build your muscle memory, and be really good at answering those interview questions.

What I found most helpful in my interview prep were studying 7 products inside out, summarizing 9 frameworks for different interview questions, and doing mock interviews for ~15 days. Those efforts will pay off not only when you get your PM offer but also when you start your new job.

Image Credit: Jooinn

I know it’s a lot, but I am sure you can do it, too.

The endless war that I’m losing

_A close up of the production facility at the Bristol Robotics Laboratory. Photo Credit: [Louis Reed](https://unsplash.com/photos/wSTCaQpiLtc" rel="noopener" target="blank" title=").

It recently came to my attention that I was waging a war across multiple fronts and fatigue had struck — they were winning. For months I had battled, fighting their persistence with my propensity to click x. I refused to fall into their traps, perfectly crafted to nullify my thoughts and…

Design Sprints can generate remarkable output for your company — such as a backlog of impactful ideas, functional prototypes, learning and key insights from customers along with real business opportunities.

Consider this situation: your company needs to solve a major real-world problem — you need a novel solution, better than any other offering available in the market. You could be aiming for a product, a component, a system, a service or a process.

In an ideal scenario, before making any investments, you would need the set of candidate solutions, prototyped and exposed to a controlled set of real users. This would enable enough signals and insights to make informed decisions and setup a better product development strategy.

To get there — from a problem to functional prototypes enriched with customer feedback — you can follow standard paths. For example you can consult the experts in your organization, assign work-streams to different teams, coordinate the work, schedule brainstorming meetings, and wait in the queue to get UI designs and then to develop prototypes — a lengthy process with several drawbacks, dependencies, issues and risks.

Or, you can setup a powerful multidisciplinary team and ‘lock’ it in a room for a few days, with a clear goal: a shortlist of inexpensive, realistic prototypes of selected high-potential concepts, each enriched with feedback from real users.

A rapid innovation process outputting potential solutions to your problem and evidence from real users on how effective they are.

This intense ideation and prototyping process comes in several forms and variations — a popular one being the ‘Design Sprint’, which promises ‘Solutions to big problems in just five days’. It uses ‘design thinking’ principles and introduces several techniques, tools and rules.

The success factors

To get real value from a Design Sprint, you must emphasize on the right setup, preparation and readiness — or you may end up hosting an expensive multi-day brainstorming session outputting just noise.

Having joined a large number of ‘ideation and prototyping’ sessions along with 10’s of formal ‘Design Sprints’, I would summarize the critical aspects and success factors in the following way.

1. Define the problem statement

Don’t let the problem statement become your real problem! Most of the unsuccessful Design Sprints and prototyping sessions I have experienced so far, share this specific single point of failure: a poorly defined problem statement, which triggers time-consuming discussions, iterations and unnecessary regression — setting the entire process at risk.

In contrast, the Design Sprints that started with clarity on the problem to be solved, moved on rapidly towards impressive solutions and prototypes.

The Design Sprints that started with clarity on the problem to be solved moved on rapidly towards impressive solutions and prototypes.

Although the first day of the Design Sprint is usually about framing and re-framing the problem statement, I am convinced that having a good problem definition upfront is key for a successful outcome. You can always revise it and reset it as necessary during the first day, but a solid basis can make the difference. In any case, the team needs to be open to understand the problem and ready to consider different angles and unconventional approaches.

There are several templates and methods to help you construct a valid problem statement — in general you need to describe the current situation vs the ideal state and the related implications for the involved users.

2. Set up the right team

The synthesis of the team sets the foundation for the entire Design Sprint — you need diversity of thought, skills and perspectives along with expertise and creativeness — all combined in a small multidisciplinary team with the right culture: a team willing to share, collaborate, challenge assumptions, think big but also be pragmatic and purpose-driven.

A few factors can introduce serious risks to the process:

• The wrong dynamics in the team (for instance, members do not express their ideas for fear of getting criticized by more senior members in the team)
• a large team (add more than 6–7 people and you’ll get additional problems to solve)
• or the wrong mindset (people tend to protect ideas versus sharing, or believe that they know the right solution, upfront).

The members of the team must ‘forget’ about seniority, hierarchy and authority. They need to be open to new ideas, new perspectives and different views. They also need to be ready to influence and get influenced, and to minimize the impact of bias and work together towards a shared mission — a great solution to a challenging problem.

Physical space is also very important to allow the team to focus, express random thoughts and ideas, collaborate and quickly visualize concepts. You need a room with enough space, the right equipment and office supplies– such as writable walls, whiteboards and well, plenty of sticky notes.

3. Make sure the team is well-prepared

Design Sprints are demanding — fast and intense. The key to success is to have a well-prepared team. Even if your dream team consists of domain experts and senior business leaders, they all have to put some extra effort to get prepared — so they fully understand the problem and its wider context, the technology, the competition and the relevant global trends. Make sure that you clearly communicate to the team not only the context and the problem to be solved, but also the rules and the need to get prepared.

4. Focus on ideation

Assuming that a solid problem statement and the right preparation is there, the next most important element is ideation. While the Design Sprint process provides some tools to empower ideation, I would strongly recommend that you:

• increase the time allocated to idea generation, sketching and pitching and
• capture the ideas in digital format — with more detailed descriptions.

A backlog of ideas is a great asset — one of the most important outputs of the sprint and the key input to the prototyping phase. Ideas should not be left on sticky notes — even the non-selected ones could prove to be relevant and valuable in the future.

This is why you need to feed the ideas generated in the Sprint into a centralized ideation system and make them discoverable by the right audience.

5. Get ready for ‘rapid prototyping’

Delivering realistic prototypes is a critical part of this process — since they will be used to capture user/ customer feedback. You don’t want your great concept to receive negative feedback due to a poor prototype implementation — that could mislead related decisions and undermine the overall value of the Design Sprint. Your team must be capable of real rapid prototyping — able to build realistic user experiences in just a couple of days or less.

Rapid Prototyping requires the right resources in the team along with a general technological readiness. For instance, to speed up the process you need to leverage any reusable software components you have, standardized datasets, artificial/ static data, UI elements, APIs, models and services. You will also need systems, tools and processes — for instance wireframing, software development environments and DevOps capabilities.

Availability of special equipment might be important. For example, if physical prototyping is involved, a 3D printer might be of real value. Or if you expect Augmented Reality prototypes, you will need access to related devices — along with any templates, APIs and documentation.

6. Find a great Facilitator

This is a key role — in fact, I see the facilitator as the real protagonist of the Design Sprint. The facilitator must maintain the right pace, direction, energy levels and interaction patterns, to lead the team towards a clear, shared goal: define and prototype a great, novel concept solving the problem for real users.

It is a difficult profile to find — you need somebody mastering the process itself, but also having deep understanding of the problem and the particular business context. The facilitator must be capable of ‘reading’ the characters in the room and take necessary action to make sure that all voices are heard and considered.

7. Capture everything

Design Sprints are typically very ‘noisy’ with tons of sticky notes, ideas and stories on the walls — all these, in-between discussions, arguments, decisions and random thoughts. And yes, this ‘controlled chaos’ is exciting, but unless you have a dedicated person responsible for taking (digital) notes, you will end up frustrated, trying to decode colorful sticky notes and ‘reverse-engineer’ random drawings.

To make the most of the thoughts and ideas, you need to capture them in a modern way — so they are discoverable and potentially usable.

8. Find a Leader, not just a ‘decider’

I find the proposed decision-making process — with the super voting concept and the sticky votes on the sketches — oversimplified and very sensitive to team dynamics and the overall state of the team. Moreover, given the extra power, the decider must demonstrate deep understanding of the concepts, the ability to think strategically and communicate with clarity. You need a real leader there, not an ‘authority’ or ‘political’ person.

The facilitator and the team should feel free to challenge whatever decisions made by the decider, by asking for justification — the business or technical reasoning.

9. Measure Success

A design sprint is an expensive process — consider the associated direct and indirect costs of having x members full-time for z days. Thus, measuring the success of the Design Sprint itself is important. In the case of an ‘isolated’ sprint, success can be measured by processing direct feedback, outputs and mid-term outcomes — for example business opportunities and success stories linked with the deliverables of the Sprint.

If you are running successive Design Sprints, you need a framework to capture and quantify Sprint outputs and impact — a flow towards a centralized ideas and knowledge repository. This data store should enable full tracking of the real business opportunities and financial gains associated with each of your Design Sprints — while specialized KPIs allow tracking the success of the overall innovation programme.

The key question in this case is regarding the baseline to compare this ‘quantified innovation output’ against — to be covered in a forthcoming article.

Design Sprints can generate remarkable output for your company — such as a backlog of impactful ideas (also with IP opportunities), functional prototypes, learnings and key insights from customers along with real business opportunities. At the same time, assuming proper and frequent execution, Design Sprints can lead to significant cultural improvements towards the ‘innovation mode’.

How to build Software Prototypes in rapid mode
_Best practices and guidance on how to rapidly build software prototypes and test your ideas to real users_medium.com

References

• Problem statement — https://en.wikipedia.org/wiki/Problem_statement
• Design Sprint book — http://www.gv.com/sprint/
• Design Thinking — https://en.wikipedia.org/wiki/Design_thinking
• Photo by Will H McMahan on Unsplash
• Related: How to lead innovation and drive change in engineering teams

Related articles

• Startups and the Importance of Agile Product Development
• Rapid Prototyping practices for Software Engineering teams
• How to lead innovation and drive change in engineering teams
• How (and Why) to Write Great User Stories
• How to become a great Product Manager
• Is this a prototype or an MVP? Well actually, it’s a proof of concept.
• How to setup and lead a great product development team
• Technology Innovation — Trends and Opportunities in 2018

MVPs always seem easy to execute and build. The first version is shipped with a few features and development is simple to manage.

This simplicity affords a focus that is disciplined and strong, because those initial features stand for the core idea.

However, as an idea grows, so do its changing product priorities and ever increasing customer feedback demanding change. What was once a simple product vision can become something verbose. You can lose sight of what made it mean something to people in its initial simplicity.

The Problem

Technology companies typically have either a top-down or bottom-up approach to product development.

A top-down focus usually means that leadership directs all product decisions. A bottom-up focus is driven entirely by research and feedback.

Beauty lies somewhere in between, when these two approaches are taken together. But when one weighs in more, problems start to occur.

Top down focus

Characteristics of a top-down approach to product development typically look like this:

• Investors tell leadership what to tell the product teams to build
• Investors and leadership hold meetings where they make decisions about the product without a lead product team member present
• Leadership team gives the product team a list of features they want to be built
• Leadership changes sprints mid-way through because they want something added or changed immediately
• Leadership plans sprints and directs the product roadmap, whereas the product team simply executes with no involvement in those decisions

Bottom up focus

On the other side, a bottom-up approach usually looks like this:

• Leadership stays out of product development in general and focuses on setting business priorities in the form of goals, visions, and strategies
• Leadership has frequent meetings about the direction of the product with suggestions in hand, but typically accepts push back on their suggestions from product team leads
• Leadership makes suggestions, but the product team leads always have the final call
• Leadership avoids and rarely engages with individuals in the product team (designers, developers, and so on)

Any of this sound familiar?

These characteristics can paint a picture of any product development environment at a startup in the last few years.

So what is the problem with all of this?

It comes down to communication.

The communication of ideas about how to make the product better while keeping it in line with the original vision.

People generally don’t like confrontation. Depending on how top-down or bottom-up the environment is, the degree of honesty people display is going can be vastly different.

This is because people don’t like to know that their ideas and suggestions aren’t very good … and people don’t like to tell people that their ideas and suggestions aren’t very good.

When this honesty isn’t enforced and managed, it can take the original product vision on a rollercoaster ride of changes. These changes are sometimes hard to spot in the beginning, but can result in disasters over the long term.

Solution

Product themes

Product themes are the gatekeepers that are summoned to protect the team’s focus and make communication between people more honest.

Product themes sit at the table when people are talking and making decisions about the product.

You can think of themes like the secret service or the armed guard. They have sworn an oath to protect the team’s focus from being hurt, lost, or altered in any way.

Instagram used themes, and we can all agree that they’ve done pretty well to keep their product under control.

“In the early days of Instagram, Krieger and his team recorded their action items in a rolling Google Doc, organized by themes.” — Source

Product themes act as a negotiator between people, because they interject and help facilitate people’s ideas about or related to product development.

“One of our themes was being the fastest photo-sharing app in the world. What are we working toward within that theme? Next, we wanted to make the photos look incredible, way beyond what you’d expect from a cell phone. What are we doing on that? Anything that didn’t fit into those things went by the wayside. “ — Mike Krieger, Instagram

“Anything that didn’t fit into those things went by the wayside” — this is the important piece here.

Instagram used themes to keep their focus in check.

It would’ve been easy for the Instagram team to hold a meeting and accept suggestions. But these suggestions could have taken them away from the focus of “becoming the fastest photo sharing app in the world” if that theme wasn’t defined clearly before.

This is because communication generally has the most impact on focus during meetings. People easily impart views based on assumptions that can lead their focus astray or down another path.

Imagine if Instagram did not have that theme at the core of what they were building, and instead took suggestions as they went along (like in an Agile environment).

What if they looked at what people wanted at the time — adding more granular photo editing tools — and tried to implement that? Perhaps Instagram would have been closer to what Adobe Photoshop is.

But instead, their product themes protected this from happening. They ensured that the communication between team members was kept on track. And people didn’t have to feel like they were being swept aside or not valued by their team. It wasn’t Mike who said an idea wasn’t good. He used the themes to justify his opinions, so there was little confrontation.

Essentially, product themes give people permission to tell any team member that what they are saying is distracting the team from the core focus.

Where do themes come from?

Product themes come from the creators beliefs about life or the problem they are trying to solve.

Themes have depth and are often rooted in strong beliefs about what should be true about a product or its impact on the world.

A theme is a big idea, and it usually touches on human experiences that everyone can relate to (so they are not technical descriptions).

How they work

To create a product theme, you must come up with a set of statements that embody strong beliefs and convictions about the product itself.

Instagram’s main theme was: “to be the fastest photo sharing app in the world.”

This is strong assertion and a clear message that has depth. People looking at Instagram today and would probably say that it embodies that theme.

Instagram’s users support and drive that theme when using it without even thinking it about it — the theme is in the product’s DNA.

When a team is having discussions, planning the execution of the product, this theme must be present and “at the table” with them every day. While the theme is present, it permits the team to discuss only ideas and information that make that theme become a reality.

I guess you could think of a theme as spirit that wants to live in the real world.

It wants you to make it real and protect it from being anything other than what it wants to be.

This is why I believe product themes can be a simple framework that protects the team’s focus and makes the way we build products more inclusive and effective.

How to use them

In order to take a structured approach when using product themes, you must first adopt the mindset of Shipping VS Learning. In this mindset, teams prioritize learning as a regular deliverable over shipping stuff. This is the underlying method that guides how product themes can be used to drive product decisions.

Here are some things that can go wrong when teams ship stuff without product themes guiding them:

• Teams ship inferior or non-impactful products in order to say they shipped something
• Teams ship things that teach their company nothing
• Teams aren’t given enough runway to do great work because of the constant pressure to ship ASAP

On the other hand, learning as quickly as possible and making sure that learning is prioritized is the most likely contribution to product success. Shipping is part of the learning process, but learning comes first.

A Sprint template

Here is what a theme-based sprint could look like over the course of 2 weeks:

• Product theme: make achieving any career change the easiest journey possible
• What we learned: Removing steps from our onboarding experience did not reduce user confusion. Instead, clearing up language such that users felt they were making progress resulted in the greatest gains (link to more details here).
• Cost to learn: One researcher, one designer, and one week of their calendar time cost €200 in user participant fees.
• Plan to proceed: Productionize new language within one month.
• What’s needed to proceed: Some internationalization help… we’ll outsource this.

According to Shipping vs. Learning, What we learned is the key deliverable, and it’s something potentially interesting to many people across the company.

Cost to learn is a chance to optimise for and highlight efficiency, as spending a year of engineering time carries much greater opportunity costs than running some efficient, qualitative testing.

Plan to proceed lets people know the outcome of the learning and how it affects the way forward.

And finally, what’s needed to proceed spells out what a manager, executive, or anyone outside the core team can do to help.

It can be very easy to spend weeks and weeks shipping product then learn absolutely nothing about how the product theme is going to be realized. This is why it’s so important to learn and spend time rethinking how people within the team approach learning and contributing to how product themes.

Sprints should be organised by each of the product themes, where tasks follow whatever system you are already using. Incomplete tasks under each theme can be pushed along to another sprint, but the identity and purpose of every sprint is never lost.

It isn’t about what are we shipping this week. It should become what can we learn this week to realise the product theme better than we did last week.

Wrapping up

In conclusion, when building a product it is imperative that a narrative is made around what the core themes are and how your team prioritises development efforts around them. Everyone within an organisation should be made aware of what the product themes are so that everyone has the opportunity to manage the overall development towards realising them.

Product themes are not an afterthought or something related only to the product’s department. They should be respected and managed just like a company vision or mission statement. I would even suggest that, in some cases, product themes are the foundation to a long lasting company statement of purpose.

All it took was this simple weekly approach and patience.

Building and promoting a new consumer product is one of the most challenging things you can do as an entrepreneur. While there are many approaches on how to design, test, build and promote apps, usually they don’t seem to bring real results.

Then you start wondering, maybe it’s the product? Maybe there’s not enough market fit? Or is it bad execution? Or maybe we should grow the marketing and branding budget! Maybe we’re not targeting the right audience? Maybe we should build more features!

When you start questioning everything, things usually get even worse. You start defocusing from the main goal and start wasting energy and money on all kinds of wide approaches.

The worst is when you think it’s all a matter of growing your marketing or branding budget.

Your goal should always be one: improving customer retention. For those who are not familiar with what customer retention is, click here.

A case study: why it’s important to keep your customers around

To make my point clear, I’ll let you in on a story I heard from a friend of mine, who’s the Co-founder and CTO of a very successful productivity B2C company.

In 2012, they released the first version of their app to the Android Google store, and a crazy thing happened. Within a few days after the launch, 500K users worldwide had downloaded the app. The reason for that crazy growth was mainly because there were no good apps in the productivity space back then. Over the next few months, they had grown to a few million users and raised over $5M from VCs.

Four years later, however, they still couldn’t reach a decent business model. He realized that despite the big numbers, there were very few users who were actually using the product long term.

So he decided to dig into the data and look for the reason. He found out that retention was very low. Even worse, he discovered that it hadn’t improved much in four years! That’s when it hit him to focus on retention instead of user growth.

Back then, VC’s poured millions of dollars into companies with large user growth because they didn’t know how to deal with or measure the crazy scale that mobile app stores and websites brought with them.

Today the case is different. The first thing you’ll need in order to raise money in B2C is to show retention growth. And there’s a very good reason for that.

Back to my friend’s story: with no retention, it didn’t matter how many users had downloaded their app. After a week, 95% of users stopped using the product. So even if they had a billion users, after a few weeks it would only be a number in their database.

Here’s a thought: if you have 100K users using your product every day, it’s 100X more valuable than having 100M users using your product once a month.

Most importantly, once you’ve reached a decent retention rate, you can be sure that your marketing budget will lead to the sustainable growth of your product and business.

The Lean Startup approach

Too many startups begin with an idea for a product that they think people want. They then spend months, sometimes years, perfecting that product without ever showing the product, even in a very rudimentary form, to the prospective customer. This is where the Lean startup comes in.

In short, the Lean Startup is a methodology that posits that every startup is a grand experiment that attempts to answer one main question — “Should this product be built?”

A core component of Lean Startup methodology is the build-measure-learn feedback loop.

The first step is figuring out the problem that needs to be solved, and then developing a minimum viable product (MVP) to begin the process of learning as quickly as possible.

Once the MVP is established, a startup can work on tuning the engine. This will involve measurement and learning, and must include actionable metrics that can demonstrate the cause and effect question.

Whenever my team and I are working on a product, here are the steps we’ve:

1. Define the most important product assumption
2. Design and build an MVP of how this assumption should be tested
3. Target early adopters to test the MVP
4. Apply the test results
5. Repeat

This is how our growth looked in the first year (2017) of iterations:

User activity from March 2017 to January 2018

Slowly but surely right? Now let’s look at an example together and see what happened after enough iterations.

The process

Define the most important assumption

I’ll use my team as an example. We believed that there were no decent reminder apps that people actually like to use. The main reason, in our opinion, was that there is a lot of friction in setting a single reminder. Either you need to fill out a long form on a mobile app, or naturally ask an assistant like Siri — realizing that she doesn’t understand 50% of your requests.

So that’s when we defined our most important product assumption: if we could achieve understanding for almost every reminder request in natural language, users would use such a product long term.

Design and build an MVP

Since our assumption was focused on NLU (natural language understanding), we decided to focus solely on that. No branding, UX, or other features.

First, we hired data scientists to build a state of the art NLU algorithm for understanding complex reminder requests.

Secondly, since all we were validating was this assumption, we decided to build the MVP as a chatbot on Facebook Messenger, instead of going through the long and annoying process of building a mobile app.

Please note: If we were to build a mobile app, this would not add anything to testing our assumption, and would make our MVP longer and more complicated to design and build. Moreover, it might even defocus us from the main assumption. For example, what if users just don’t like to use new apps anymore? We might’ve concluded that our assumption was wrong, even though it was for a whole other reason.

It’s important to narrow your MVP as much as possible, so there are no distractions from your main assumption.

Target early adopters

We needed English speakers, since our NLU algorithms only supported it. Also, we believed that millennial moms would eagerly want a product like this, since they’re always on the move and very busy, while constantly needing to remember things. So we targeted some Facebook pages (with no budget) which were based on a community of moms, and successfully brought onboard a few hundred beta testers to try it out.

Apply the test results on the product

After our first iteration, we learned the following:

1. There were many more ways to ask for reminders than we thought. But users really enjoyed the ease of setting reminders with a simple request.
2. Users don’t always ask for reminders in a single request but break it down into a few steps.
3. When working with chatbots, users would like the assistance of buttons to make it faster and easier to handle.

With these results, we prioritized and went on to our next assumption, which was to add buttons to the flow of setting a reminder (conclusion three). And guess what? That assumption also turned out to be true. For more proven assumptions, you can read my article on How to improve your chatbot.

Little by little, we improved our overall product and retention rate on a weekly basis.

We never tackled more than one assumption at a time.

Suddenly, we started discovering users who were with us for over six months! After a year of weekly iterations, we finally decided it was time to launch our product. We reached a Week 1 retention rate of 92% and Week 4 of 19%. It was way above the market standard, which was enough for us.

We published our chatbot on FB Messenger in mid Feb 2018, and within a month we grew by over 5,800%, as you can see below.

Daily new users from Feb 17 to March 17

This was mostly due to delivering a lean product that we knew people enjoyed and would recommend to others. Since then, we’ve grown to over 1M users worldwide and are growing by tens of thousands of users a day.

Total user growth from Jan 18' to May 18'

We’re continuing to work with this methodology, and it’s proven a success every day.

Also, we try to make as many data driven decisions as possible. Try collecting user data for improving user experience, and do A/B tests when there is no definitive answer. For example, if you’re not sure where a button should be placed or which title would attract more clicks, try placing it on one side for half the users, and on another side for the second half. Then, see which placement led to more clicks.

Final thoughts

Not only does this methodology help us focus solely on what’s the most important set of features users want, but it also helps us filter out features we believe are valuable, but that are actually not.

As they say in customer service: the customer is always right. The same goes for product development. Trust your customers, listen to them and engage with them, and you’ll understand what they want and don’t want. Never build things out of your own intuition, unless it’s to challenge your assumptions. At the end of the road, you’ll reach one of two conclusions:

1. The product does not have enough market fit, time to move on.
2. You have a product people want. Good job, you’re on the way to building a company!

Either way, you win.

Thank you very much for reading, if you found this useful, please give me some claps ??? so more people can see it. For more articles, visit my tech blog at assafelovic.com. If you have any questions, feel free to drop me a line in the comments below!