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.

In 2012, a young Czech DJ hobbyist was frustrated with the knobs and faders on his music controllers, so went looking for ways to improve them. That’s when he came across 3D printing, and one of the fastest-growing 3D printing companies in the world was born.

Today, I’m going to show you exactly how Prusa3D became one of the fastest-growing hardware manufacturers in Europe. Then you can take inspiration from their exact strategy to grow a hardware company and create a community of contributors who will help you develop and promote your project with close to no resources.

Some background on Prusa

Josef Prusa, Prusa Research’s founder, is a superstar in the 3D printers industry.

You might have already heard about him but if you haven’t…

• Prusa Research was founded as a one-man startup in 2012 by Josef Prusa.
• His goal with Prusa Research was to create a kind of Thermomix, Europe's favourite all-in-one, easy-to-use kitchen appliance, for 3D printing. He wanted to make a 3D printer that was easy enough that anyone could use it, with guidance on steps and materials.
• In 2018 Prusa Research became the fastest-growing tech company in Central Europe (Deloitte Fast 50 2018) after growing 17,118% between 2014 and 2018
• Prusa Research has grown from humble beginnings to selling 100,000 printers, employing over 410 employees, and setting up a factory in Prague with 9 floors and a hackerspace on the ground floor
• The company brought the Maker Faire to Prague for the first time
• Prusa’s website has over one million unique visitors per month, its YouTube Channel has more than 144,000 subscribers, and its forum has over 143,000 members

Josef Prusa was lucky, but also did a lot of things well that we can all learn from.

How? Let’s dive in.

How to solve a problem of your own, give back, and build trust in growing communities

Before the roller coaster started, Josef enrolled in an economics degree to make his parents proud. This resulted in a lot of spare time, so he and his brother began DJing and building their music controllers.

Josef (above), rocking his DJ skills. Little did he know how his life was about to change.

He was looking to make his own knobs and faders, but found the search into it too long and challenging. He then found the RepRap project and Mendel 3D printer.

As you may know, RepRap is a community project started by Doctor Adrian Bowyer at the University of Bath and it kickstarted the desktop 3D printing craze.

The basic idea is that a 3D printer can print as many parts as possible for another 3D printer and as a result, decreases its cost.

But when Josef was building his Mendel Printer, he was finding it too complex. It required many different screw sizes, there were no slots for nuts, and very few parts were push-to-fit.

So he improved the Mendel by making a simpler version; the Simplified Mendel [sic], and shared the designs on GitHub with the rest of the RepRap community.

The community caught up with his simplified model and started using it over the original, and that’s when people started noticing him.

Takeaways:

• If you’re a student, have spare time, and/or have no dependents, enjoy this time to experiment and try new things. What are you curious about building?
• Identify and solve a problem of your own. What tools are you using? What’s currently frustrating you about them?
• Fix or simplify what’s not working. If you don’t know how, what skills would help you? Learn those.
• Share your solution in a community that’s active and that has the same problem. You’ll benefit from exposure and feedback to make your solutions better. This way you’ll start building trust among a like-minded audience and you’ll be in touch with what people want.

How to create your first prototype

When Josef was trying to solve his problem, printers were still missing one key component to have the ABS plastic print successful: a heated bed. Without it, prints warped and deformed away from the bed.

To tackle this problem, he came up with a rudimentary prototype (shown above) which consisted of a resistance wire stuck between two sheets of acrylic. It didn’t last very long.

Without letting the setbacks defeat him, he went on to create a second version. This one used a tile instead of acrylics, which was an improvement. But still, it only reached about 90 degrees Celsius, which wasn’t enough either.

After nearly six months of persistent work, the PCB Heatbed MK1 (above) was complete. It was the first real product he created.

This new heatbed could reach 110ºC, more than enough for ABS and other high-temperature plastics.

But many parts of the heatbed were either too expensive or difficult to get, so he redid many on his own.

He soon started receiving requests to print his Prusa Mendel’s parts. He also organized a few local build events, where everybody could build their own parts.

There was so much demand that it was time for Josef to officially start Prusa 3D with his brother Michal.

What’s interesting is that he didn’t start with the company name, the logo, and so on – rather, he started with a problem he had himself, and then he shared publicly, both his problem and his solutions, with others.

By sharing what he was doing with others, people who had the same problem could order his solution. And there were many people who shared his problem, which translated into many orders.

It’s also important to appreciate the persistence and patience it takes to continue iterating for six months in order to create a product that works and one that people want to use.

Josef and his brother began selling their first parts without an e-shop and instead sold them through email and a phone number on a webpage. They also hadn’t perfectly optimized their packaging yet. In the beginning, they packed their heatbeds in a pizza box and shipped them off to their clients.

Josef and Michal didn’t let the lack of a perfect tech solution get in their way. They simply found a way that was good enough to get their idea out the door and then made it better as they went along.

They were also proactive in creating awareness and trust with their audience. In the early days, they kickstarted the community by organizing presentations and going to events to educate people about the possibilities of this new 3D printing idea.

Josef also embodied honesty in his sales. If people came to him but were looking for something he didn’t sell or was a poor fit, he just told them which technology they should use instead.

This earned him a community of loyal users who trusted him and regularly came back to share prints and hacks on the new Prusa Printer's online hub. Whenever Prusa was criticized in their Youtube comment section, a flock of fans spoke up in their defense.

Takeaways:

• Start simple before having everything figured out.
• Let go of perfectionism or trying to look like established companies. What is good enough for the stage you’re at to satisfy the needs of the people you can serve? If it’s packaging your products in a pizza box instead of providing a delightful unboxing experience, so be it. If it’s not having an e-shop but just an email and a phone number on a simple website, so be it.
• Focus on creating a solution that solves the problem for good. It might take some time, but if it hasn’t been solved yet, there’s a good chance it’s because it’s hard to solve. Being persistent and patient requires you to commit and invest at the beginning, but once you get through the other side of the problem, you’ll have something people will flock to. It took Josef Prusa six months before he found a proper solution for his heatbed.
• Be radically honest and defend the best interests of your customers. If there is someone else who can serve them better, redirect them there. This builds trust, as people will remember how you treated them with respect.

Should you do everything yourself, or delegate certain tasks?

When we start something and it gets some traction, or even if we just anticipate the traction it can get, thinking about everything that we have to deal with can become overwhelming.

There might be barcode visualization, trademark registration, label design, building walls, building websites, accounting, invoicing, digging drains, dealing with bankers, installing equipment, video-editing, dealing with customer support, and more.

Most of the time we’re not even remotely competent at more than one or two of those things.

So this is the time when we hit a fork in the road. Do we hire or outsource to delegate, or do we do it ourselves?

Prusa’s beginnings are an interesting example of how to go through this period and build for the long term. Below, Josef explains how they went about preparing to scale:

“We never had resellers so we were always in direct contact with the customers in the community and this proved very important for us because you have instant feedback from the people.

If you are just a manufacturer and somebody else is doing the selling for you, you don’t always get all the information back.

In the beginning, it was much tougher for us to do it this way because we not only needed to learn how to make the printers at scale but we also needed to learn how to run a big webshop and how to do the customer support for all these people. It was more difficult but now it’s paying off that we have this direct contact and know how to run every part of the business on our own.”

It wasn’t until October 2013, three years after finishing the initial prototype, that they hired their first employee, Hanka.

How do you get the cash flow to hire people? Well, you sell in advance and produce after. In the beginning, Prusa always had a two week lead time for customers to get a printer.

As they continued to grow, they also hired a Foxconn engineer to deal with quality and a couple more software engineers to lead the engineering team.

They could have spent months or years trying to raise funding through VC or Kickstarter in order to hire people, outsource production and grow much faster.

But they decided instead to invest in the slower and more demanding path of figuring it out on their own, and keeping contact with the customers and their needs. This path has proven to be a much better strategy in the long run.

In 2014, Prusa Research had a revenue of 149.000€, which then grew to 70 million €, employing over 250 employees in 2019 just by bootstrapping the business.

If you aim to change the system, you need to be able to exist independently of it.

Takeaways:

• Embrace DIY and learn to do the critical parts of the business yourself. What skills do you need to learn? Where can you learn them?
• Once you can no longer do it yourself, understand what needs to be done, and when you have enough cash flow, hire people to do the work with you.

What Prusa stands for

Prusa has exploded because it does a few things very well by always putting their customers' needs first without compromising their values or their price. This in turn helps them build a strong virtuous cycle for their development.

Prusa has a long-term vision

Josef knows what he wants Prusa to become. He wants his printers to be able to print any object with any material and through guided steps, much like a Thermomix for 3D printing. And he wants the least tech-savvy person to be able to operate it.

Having this clarity helps him and everyone in the company align their efforts towards a common goal.

They have amazing customer support

The company also keeps investing in the way it cares for its customers.

They go to great lengths to test every single part of their printers to ensure quality but even that isn’t enough to cover everything – so that’s why they have support.

Almost 20% of their employees work in customer support. They have 12,000 live chats per month in nine languages and deal with over 11,000 emails each month.

Prusa provides high quality products

Investing in making the designs of their 3D printers more functional, simple, and of high quality allows them to avoid competing with the nicer-looking but more expensive 3D printers.

They make an affordable printer

This means that they are not too expensive for everyday consumers, and not too cheap for companies.

They’ve also made their 3D printer upgradable because it saves money for their customers and it builds their clients’ autonomy by helping them learn about the construction of the printer’s hardware.

All Prusa's work is open source

Prusa’s clients are “normal Joes” as Josef describes them, and most don’t care much about open source. But the company does.

Those who care about open source provide valuable contributions that can be added back into the products. Some people will make improvements, some will fill in new code, and all of it helps make the printers better.

The open-source approach is also good for users. Those who want to do modifications find it much simpler because they have the original sources for the printer parts, the firmware, and the electronics.

Josef even has a tattoo of the OHSWA logo to keep himself accountable and honest to the open source vision.

Source: 3D printing Industry

Open source makes it easy for the idea to spread and upskill people who can find new use cases to increase the company’s pace of innovation, and it makes it more affordable to its clients.

They partner with distributors and support their clients even though it decreases their margins

Another counterintuitive thing Prusa does for its clients is that it supports the customers serviced by other distributors.

Many companies would forfeit this channel because it demands high margins and the distributors don’t do support. But they do these distribution partnerships anyway to make it easier for the people they serve to discover and access their printers.

And even if they make no extra money through these channels, they still give them the same level of support as those who buy from their website.

Why? Because caring for their customers is what makes it safe for them to then recommend Prusa to their friends and family, driving more business by word of mouth.

Takeaways:

• What is the long term vision of what you’re doing? What happens as you keep developing your organization? What results are you helping people achieve?
• How can you invest in better supporting your customers?
• What parts of your project can you give away for people to build and learn with you?
• What partnerships can you build to distribute your project in places where people need it?

How Prusa Builds and Invests in the Community

We’ve already spoken a lot about how much they invest in customer support, but Prusa also invests heavily in their community.

This does two things: it builds proof of what their product does in the world, and it helps scale even further what their customer support service can do.

To gather their community they do a few things.

The first thing Prusa does is offer two options to customers: They can either buy printers as kits or assembled. 80% of clients buy the printers in kits. Besides saving time in production, this allows the clients to learn how to build their printers and understand how they work.

This approach is raising a generation of makers who can create and fix instead of throw away, building a lot of goodwill for the Prusa brand.

To keep in touch with the community, in the early days Josef Prusa tried to go to as many shows as possible so that he could talk to fans face to face and hear about the awesome projects that could come to life with the help of their printers. He went to Maker Faires and to DIY or 3D-printing events.

Now that the company has grown so much, he can’t go to as many events. But before the pandemic started, there was a team of three to ten people traveling around the world two to four times a month. And they were also organizing their Maker Faire in the Czech Republic.

Takeaways:

• Where are your community members hanging out? What blogs or magazines do they read? What podcasts do they listen to? What events do they go to? What youtube channels do they watch? What newsletters do they subscribe to? Who do they follow on Twitter, Facebook, or Linkedin? What forums or groups do they participate in?
• What resources do they need to get started that you can facilitate? How can you give them the tools to create what you do?
• How can you invite users to participate in the development of your product? Can you open your files and designs for them? How can you invite them to give back and showcase their work or the skills they’re building thanks to you? Where could you use this as proof that your product works?

How to Engage the Community

Many people understand the value of giving free stuff away online to attract a crowd. But I feel that many entrepreneurs haven’t embraced the opportunity and the value of connecting the people in their community with each other.

This is a very powerful idea that can go a long way in building trust and reciprocity with your brand and in getting the community members to spread the word and interact with stories of what you do.

One more powerful thing that Prusa is doing is figuring out how to connect the isolated Maker tribe, and at scale.

Once they gather their community by giving away their designs and connecting with them at events, the next challenge is getting these people to engage. And Prusa does a remarkable job at that.

They’ve created a series of resources that make it easy for people to learn the skills and tools they need to become active members of the community.

In their online hub, they share resources for learning and practice, such as a library of 3D printing models with files, and free guides on how to start 3D printing.

Once people are on their website to grab these resources, they can connect with each other locally or online through a map or in the forums to reach out for support or to go for a beer.

As a quick overview, Prusa provides the resources needed to learn the tools and the skills required to set up and hack a 3D printer. There are manuals, such as a free ebook to teach the basics of 3D printing, assembly instructions in video and ebook form, troubleshooting guides, and of course the downloadable drivers and firmware.

Once people have what they need to learn the basics, they can jump into the Forum to talk about their printer model, stay up to date with General Announcements and releases, find those community members in the Hall of Fame, and discuss the software.

Takeaways:

• What resources does your audience need to develop the skills required to use your product and to participate in the community in order to help each other?
• Once they trust you, how can you connect them to find support among their peers? What exchanges can you facilitate or what spaces can you create for them to gather and talk about their questions?

In Summary

Prusa’s approach helped them grow over 17,000% without a sales team, only through word of mouth.

It helps that they serve the fast-growing 3D printing market, but still.

Prusa has become a big player and a beloved brand in their industry, proving that you don’t need a huge marketing team or budget to get similar results. You just need a smart and intentional plan.

Here are the key takeaways you can borrow, modify, and adapt for your own business based on Prusa’s real-life marketing tactics:

Takeaway #1: Build a skill to solve a problem of your own

What tool are you using that is not working as you wish it did? Learn the skills to fix or simplify what’s not working.

Takeaway #2: Share your solution in public

Once you create your first working solution, share it with communities who already use these tools and have the same problem as you do.

This builds trust, reciprocity, and if people want to buy your solution or they have other problems you can build on, they can tell you.

Takeaway #3: If it’s your first time, be patient

When we first start, we don’t have all the skills we need to find a solution to a problem. Be patient and persistent and embrace failure and rejection. It’s by getting into action that you’ll figure out what’s not working or missing, and what needs adjusting.

Takeaway #4: Start simple, even if you don’t have everything figured out

Let go of perfectionism or trying to look like an established company. What is good enough at the stage you’re at to satisfy the needs of the people you can serve? What is good enough for now to solve other people's problems, build your product, and ship it?

Takeaway #5: Learn to do everything yourself and become autonomous

Don’t delegate too soon. If your goal is to change the system, you’ll have to learn to be autonomous early on and stay in close contact with your customers.

When the time comes to delegate, you’ll know what needs to be done and hire the right people for it.

Takeaway #6: Be radically honest and defend the interests of your customers

If there is a competitor who can serve them better, redirect them there. It will build trust as people will remember how you treated them with respect.

Takeaway #7: Be clear on what you stand for

What is the long term vision of your project? If money and growth is a means to an end, what is that end meant to achieve? What can you do to accelerate or scale this?

For Prusa, it was investing in outstanding customer support and sharing their work in open source to create both a delightful experience and to involve outside experts in their innovation.

Takeaway #8: Find and gather your community

Go meet your community where they hang out to stay in touch with their needs and to connect with them. What forums or groups do they participate in? What events do they go to?

Once you’ve found them, create spaces for them to gather and connect. Josef Prusa started by participating in the RepRap forums and by going to Maker events. Later on, they started organizing their Maker Faire in the Czech Republic.

Takeaway #9: Engage the community

Give them the resources and tools they need to get started. Then invite them to participate in the development of your product by opening your designs.

For those who contribute, you can showcase their work and skills to show your gratitude, and use these contributions also as proof that your product and community work.

Thanks for reading. Inspiration for this article came from The Road to 100,000 Original Prusa 3D printers. You can watch it here:

When you're building a product, there are different frameworks you can deploy to think critically about what to build and why. These frameworks apply to business as well.

When designing a product – or launching a startup – you should answer a few fundamental questions:

1. Should I enter the market or not?
2. Who else exists in this market and what are these firms doing or building?
3. What are the costs of entering this market? Are these costs fixed or variable in nature?
4. If I decide to exit the market – or stop building or maintaining my services or software – what are the costs?
5. Who will use my product or services and what do they value or need?
6. Am I uniquely equipped to help these people or constituents?

This article provides an overview of four interesting, dynamic, and different approaches to probe your assumptions and answer these questions. Ultimately this article is about strategy.

Strategic thinking is about the art of outdoing an adversary knowing that they are trying to do the same to you.

Albert Einstein once asked, “If a cluttered desk is a sign of a cluttered mind, of what, then, is an empty desk a sign?” Just because a desk is empty does not mean it’s not contributing utility. For strategies to be effective they too need to be useful, applicable, and relevant.

Oftentimes building a company – or creating a piece of software – is about the application of strategy.

At a more granular level, this article attempts to help you think about the above questions by leveraging mechanisms for transforming inputs – like data, beliefs, and research – into a desired set of outputs that are easy to deploy in your everyday life and useful.

I have learned about these frameworks through a mixture of reading product launch templates, building products with my own hands, and studying how other product and business stakeholders optimize their work to drive the outcomes they desire.

I want to explain each framework and pass on the most salient takeaways from each so that you can rapidly apply these frameworks and build more effectively.

Framework #1: The Airplane Crash Test

Reginald H. Jones, the Chief Executive Officer of General Electric from 1972 to 1981, was in search of a successor upon retirement. He asked each of his executive subordinates a question:

“A plane crashes and you are on the plane. You don’t survive. Who should take over running the company or building the most important products, and why?”

This is an interesting question to ask yourself, and is especially salient as you build and scale products. Who do you know that is best suited to be the leader in an environment filled with ambiguity?

In your mind, is it you? Is it a peer? What does this person do so well that inspired you to think of them? Try to replicate their behavior and knowledge base to better equip yourself as a builder and product developer.

If you did select yourself, think about why. What skills do you have (technical, business, political, and so on) that can help you drive an organization or product forward? How will you teach those skills to others?

By thinking through the airplane crash test you can reflect holistically on what you do well, why those skills matter, and areas for improvement. You can also gain a deeper sense of appreciation for the skills that others in your life – or on your team – may have.

Framework #2: The Airport Test

This framework is very different from the airplane test. In this thought experiment, ask yourself the following: if I were to be stuck at an airport for many hours with someone, what kind of person would I want that person to be? And secondly, if others reflect on the types of people they would want to spend time with, am I one such individual?

Google famously applied an “airport test” to help conceptualize the types of people it would want to hire. On one hand, the airport test lends itself to some admirable outcomes.

If you are stuck at an airport for many hours with someone, it makes sense that you would want to surround yourself with someone who is curious, insightful, and easy to communicate with. These are valuable skills to cultivate in life, and as a builder.

On the other hand, this test has limitations – and the biggest one is seemingly bias. Would you rather spend more or less time with someone who thought and acted like you?

If so, you might be overlooking great people to learn from and spend time with that differ from yourself.

When building products at scale, you will want to think about all potential users. Many users are different from you and come from different walks of life. Think holistically about these users and who they are – their wants, needs, and diverse backgrounds – so that your product or business can best meet their needs.

Think about the airport test as bi-directional. Try to be the type of builder, motivator, or creator that others want to spend time with. Look for others that meet that test for you, too.

Framework #3: The Working Backwards Framework

Working backwards is a framework practiced by many product builders because it helps set a North Star rooted in customer feedback.

At its core, Working Backwards is a belief system that states that you should speak with users and customers and listen to feedback about what to build and why. The product designer, after organizing this feedback, can start building tools and services that users care about and want.

By working backwards, a builder can save time and money.

Amazon Founder Jeff Bezos once noted that while he can’t predict the future he can’t imagine a future in which people want slower delivery or higher priced items.

By working backwards from the fundamental needs and goals of users he can build solutions, technology, and products that empower these people.

Many great products that you leverage in your daily life are predicated on designers looking at the needs of users and building based on those inputs.

In the case of image searching technology, coders literally saw that people had an end goal of using images to run searches. Working backwards from that destination enabled the creation of reverse image search technology.

When you are building, try to place yourself in the shoes of users and go speak with them. By building relationships and starting these conversations you can be guided by what your users actually care about.

Once you know what matters, you can obsess over the details that best help you help your users. That is what the Working Backwards method is all about.

Framework #4: Jobs To Be Done

A fourth and final framework for understanding how to build businesses and products is to think about why people are “hiring” your technology and what problem your technology solves.

The late Clayton Christensen of Harvard Business School famously argued that the “customer is the wrong unit of measurement”. Instead, Christensen noted, people use solutions for “jobs to be done,” or the pain points they face in their lives.

When you are building your next piece of software, or product, or business, ask yourself: why are people hiring me to do this job? If you believe that your customers are rational, evaluate their behavior.

If you think that your rational users are making irrational choices, take time to better understand how your tool is actually being used.

By framing your work in this light you can develop and hone in on a very important skill set for builders to cultivate, and that is empathy. If you can’t empathize with how your product is being used (and for what purpose) you won’t be able to empathize with your users.

Bringing It All Together: Frameworks for Development

I have outlined four different frameworks to help you think about your work, how you devise products, and ways to conceptualize the development of your software or products across users, time, space, and markets.

These frameworks are not mine but represent interesting and influential nuggets that I have picked up watching others. These nuggets have influenced how I think about design, feedback, and content, and I hope they are useful for you too.

The application of these frameworks can help you build.

You can apply all, some, or none of the above. However, my hope is that by thinking about these questions and approaches you can dive deeper into solving real problems for real users and that you can better develop the skills, product design mindset, and empathy to align your products with the needs of your current or future users.

I spent a year learning how to build products. Rather, I spent that year learning just how hard it is to build good products.

It's been a roller coaster ride so far and I want to share my learnings.

I'm going to highlight the most important lessons I've learned along the way.

What to Expect from This Article

Before I start, I do want to specify that this blog post is not as technical as most things you will read on freeCodeCamp.

While exploring the technology will be valuable, I believe it is just as beneficial for programmers to look at the business aspect of things. This is in part because it is not something most programmers pay attention to.

As programming becomes more and more popular and commoditized, it will become more valuable for programmers to understand exactly how they are adding value to a company.

Answering the why of problem solving is the most crucial business aspect while building technological solutions.

A Bit of Background and Context

I work at a garment manufacturing company headquartered in Bangalore, India. Nope, you read that right. I work in tech at a garment manufacturing company in Bangalore, India.

Not the most glamorous of jobs, but it does provide a lot of opportunities to experiment.

The garment industry is one of the most unorganized industries in India. For people working in the tech world, it's a little hard to grasp just how unorganized it is.

When people in tech think of a problem, they think of sifting through large sets of data to glean insights that might turn into more effective features.

But, what do you do when the data is still written in pencil on paper? How do you even get access to that information?

Sometimes it feels like the rest of the world stormed ahead leaving certain industries lagging far behind that. And it often feels like the wheel of invention is coming spinning back around again.

How Things Work at the Company

Before I can present the problems, I need to explain how a garment manufacturing unit works.

Here is an extremely simplistic overview of how the supply chain in garment manufacturing works

Pretty simple, right? It really is! And just like every other industry, the devil is in the details.

Let's dive in a little deeper. For brevity's sake, let's examine just the relationship between the textile mill and the garment manufacturer.

It starts with an order placed by the buyer with the garment manufacturer. The buyer will tell the garment manufacturer that they require a specific kind of fabric for their garments. This is called a style of fabric.

Now, when we refer to the style of fabric, it can mean many different things. Here are a few of the variables that comprise the style of the fabric.

For now, to keep things simple, let's just focus on fabric colour.

The garment manufacturer will then place an order for the fabric with the textile mill. Once the textile mill is ready to ship the fabric, the complexity starts.

The problem is one of scale. When you have over 30 suppliers of fabric, stationed all over a country, keeping track of when you get shipments of fabric is hard.

How We Can Define the Problem

Here are the key problems:

• Keeping track of when you receive the fabric shipment
• Keeping track of how much fabric you've received
• Keeping track of which supplier you've received the fabric from
• Keeping track of which location you've received the fabric at
• Whether the fabric passes quality inspection checks
• Whether the fabric passes the lab tests indicated by the buyer

Our problem is going to focus on only the following three points:

• When did we receive a shipment of fabric from a supplier?
• How much fabric did we receive in a specific shipment?
• At which location did we receive the fabric?

The most obvious solution is Excel sheets.

Lesson #1: In big organizations, Excel functions as a distributed database.

Excel works well, for a while, and then quickly becomes difficult to maintain.

Why? Let's start a hypothetical garment manufacturing company to answer that.

Phase 1

Okay, so we've just started and we have 2 suppliers, 3 factories, and a head office. That's pretty good for a start!

Let's also say that we have 1 buyer. Having a single buyer means that the number of different styles of fabric that we have to deal with are small.

As and when each factory receives fabric, they let the head office know via email the amount of fabric and the style of fabric they received. Then the head office puts that data into an Excel sheet.

Each factory receives fabric once a day, so that means the head office will receive 3 emails a day. Not too bad!

Even if a supplier delays a shipment, it's relatively easy to track because there are only 2 suppliers.

Phase 2

Things are going well, business is growing, and you decide to expand. You set up 5 more factories.

You also increase the number of buyers you're working with, which in turn increases the number of styles of fabric.

You also want to increase your turnover, so 3 of the factories receive fabric twice a day: once in the morning, once in the evening.

Things just got a little more real.

You'll notice that each supplier's face is now invisible. This is not a coincidence. Yeah, I did it to save space but I also did it to illustrate how as scale increases, your personal relationships with business partners take a back seat.

It's simply not possible to maintain the same kind of personal relationship you had with 2 suppliers, with 6 suppliers and 8 factories to boot!

You might wonder why the above point is relevant. That's because it leads into the next lesson.

Lesson #2: Business relationships are built almost entirely on trust, especially in the absence of technology.

Let's examine the lesson above for a bit. It's important because the goal of most technological systems is to eliminate the need for trust. Of course, that's not entirely possible.

Before continuing, there is one quick thing I need to mention. When suppliers provide fabric to manufacturing units, they usually provide it in the form of a roll of fabric.

Let's construct a scenario with you as a garment manufacturer. You have a supplier who provides you with rolls of fabric.

One time, you receive 10 rolls of fabric and based on an anonymous tip-off decide to measure the length of each roll of fabric against what the supplier tells you it is.

The above infographic shows you what that would look like.

To your dismay, you find out that the supplier is cheating you and you're short 36m of fabric. In a low-margin industry like garment manufacturing, this counts for a lot.

Also, this was only for 10 rolls of fabric. As your company grows, you're going to order more rolls of fabric from a supplier. Imagine you had a 100 rolls of fabric to go through instead of 10.

Manually checking each roll of fabric is not an operation that can scale, and as your operations scale, trust becomes more important.

Now, back to our problems of scaling. We have a total of 6 suppliers, 8 factories, and more buyers – and therefore more styles of fabric.

With 5 factories receiving fabric once a day and 3 factories receiving fabric twice a day, the head office will receive 5*1 + 3*2 = 11 emails a day.

Things have gotten harder not only because the head office is receiving more emails but because the styles of fabric they are receiving have also increased. This adds to the number of rows in an Excel sheet.

Now, when a supplier delays a shipment, things get a lot harder to keep track of because the factories are receiving 11 shipments a day from 6 different suppliers.

But, even now, Excel is not a bad option at all. However, the fabric department is under a lot of strain trying to keep up with the workload, so the head office does what any good organization would do and adds a couple more employees.

Was adding two employees a bad idea? All answers are opinionated.

A technologist would say: "Why would you add two more employees? You need to simplify the process by adding automation!"

A CEO would reply: "Why? The cost of automation is not worth it. It's simpler to add two employees and keep our process the same."

Lesson #3: Not everything is worth automating. This is the hardest lesson to accept for me.

Relevant XKCD

Phase 3

Time passes and business continues to boom. Being a capitalistically inclined CEO, you want to increase the scale of the business again!

This time, you increase the number of factories to 14. You also add more buyers to the portfolio, so this increases the number of styles of fabric the factories need to work with. 6 factories receive fabric twice a day and the remaining 8 receive fabric once a day.

You also work with 20 suppliers now because of all the different styles of fabric you require.

I haven't bothered to name any of the suppliers or the factories in the image above cause it would be too much effort.

But, again, this is to illustrate that the personal relationship you might have had with each of the managers of the factories deteriorates. You simply can't maintain each of those relationships to the same degree.

Now, the head office will receive 8*1 + 6*2 = 20 emails a day! Each email also contains more data because we increased the number of styles we are working with.

Maintaining a manual central Excel sheet becomes harder and harder. Simply adding more employees to the task also won't necessarily help because you might just end up with multiple copies of a centralized Excel sheet in the head office.

How To Solve The Problem

Now, there are multiple ways to solve this problem.

One could be to ask each of the factories to maintain their own daily Excel sheet and send it as an attachment via email to the head office.

However, this again involves someone copying and pasting the data from each factory into one centralized Excel sheet. Nothing wrong with this, but there is probably a more efficient solution.

Another potential solution is we could ask each of the units to maintain an individual Google Sheet and run a script using Google App Script every day like a cron job and pick up the data.

However, if you want more data like the length of each roll, you're out of luck. There is no way you can ask people working in factories to manually enter the length of each roll of fabric everyday. Because, like we said earlier, you could potentially receive 150 rolls of fabric a day.

Our Solution

The solution we ultimately went for, at my company, isn't a surprising one: we decided to use barcodes.

We place a barcode on each roll of fabric. The barcode correlates to the length of a roll, the style of fabric, and which buyer it's for.

We built a small Android application that allows users to scan barcodes with the device camera, and on each scan hits an API indicating that this specific barcode was scanned in a specific location (picked up via GPS).

Scanning a roll of fabric allows us to pick up the location of the roll via GPS and the date and time.

Adding up all the rolls of fabric scanned at a location allows us to know the total length of fabric received by a factory.

Best of all, this reduces the workload for the factories themselves. Their only job now is to scan the rolls of fabric. Scanning one roll of fabric takes ~3 seconds, so scanning 100 rolls of fabric takes ~5 minutes.

Here is a basic schematic of what we built:

• A web based application that is used to generate the barcodes
• An Android application that is used to scan the barcodes
• An API that both the web app and Android app communicate with. The API in turn communicates with the MySQL DB.

The whole thing is hosted on AWS and the Android app is hosted on Google Play Store.

The solution seems simple enough, but it isn't.

What We Learned From Solving The Problem

Lesson #4: Building things for people is hard because there is often a disconnect between the people building the thing and the people the thing is being built for.

This disconnect is why it's a great idea to build a product that fulfills a need you've long wished existed.

One of the first mistakes we made with the Android app was giving our users too many options

The sketch above shows what a very early verion of our application looked like. Clicking each of those buttons took you to the camera screen. However, each of them made a different API call and so returned a different result.

The rationale for including the Enter button was that, if the barcode were to get scratched and couldn't be picked up by the phone camera, the user could then enter the barcode instead and it would count as a scan.

Here's what one of our barcode numbers looks like: k29_%!s5qG. There is no chance that anybody is going to sit down and enter that sequence of characters.

The rationale for the Read button was that if someone were to want to identify what kind of fabric a specific roll was, they could scan the barcode in Read mode and it would return information about that roll of barcode.

The factories already had their own method of storing information about the roll, though. They just wrote it down in pencil and paper and stuck it to a tag that gets attached to the roll.

Is it the most technologically advanced system? Heck no! But, does it work? Heck yes! And we should have respected the fact that they already had their own way of doing the same operation.

The end result is that almost no one even bothers clicking on either of the Read or Enter buttons.

When building things, keep things to the bare minimum. There is no reason to add additional features unless absolutely required.

The second mistake we made was not knowing our audience.

When we came up with the idea of building a web application for people to use to generate barcodes, it seemed like a no-brainer.

We ran into a funny problem, though.

When we explained to the people working in the factories that they needed to enter the address into the address bar, we got blank looks in response.

You see, with the privileged background most of us come from, we tend to forget that there is a large majority of the population that doesn't know how to interact with a web browser. Why? They've never had the need to. They interact with the internet primarily through smartphone apps.

This might seem like a bit of a stretch but I've seen the evidence with my own eyes. This is not to suggest that people who don't know how to use a browser are less intelligent by any stretch of the imagination. It simply means that we need to communicate things to them differently.

Now, this topic of communication brings me to the final lesson I've learnt. Probably the most hard-earned lesson and definitely the most insightful.

Lesson #5: All problems in an organization are communication problems.

Look back at what we've covered in this article.

The first issue we uncovered was the issue of emails. When an organization is small, fewer emails are exchanged. As an organization scales, the number of emails increases and it becomes harder to keep track. Communication problem.

The second issue we uncovered was one of trust between the supplier and the manufacturer. The supplier communicated wrong/false information to the manufacturer. The manufacturer had to spend valuable time correcting this false information. Communication problem.

The third issue we uncovered was how to explain to people who've never used a web browser, how to navigate to a specific page. Communication problem.

I know it sounds a little like pigeon holing where I'm trying to force every problem into a communication problem, but at the heart of most problems is just that: poor communication.

Conclusion

I glossed over the more technical aspects of the solution we built. However, I think that is not the interesting part. What is interesting is how we've attempted to solve problems.

If you think the problems I am working on are interesting, take a look at our job listings.

If you can't find a role that suits you in the listings, please shoot me a mail at zaid@indian-designs.com.

Would you use product X?

Do you like product X?

What do you enjoy most about the user experience?

These questions all elicit feedback. However, these questions are broad. If you want more specific feedback that you can transform into changes to your product, you will want to ask questions that elicit more details.

If this insight seems obvious, why do we - as builders, designers, and coders - all too often ask for product feedback that leaves us no better off than we were before asking?

I believe - and will provide examples to support in the article that follows - that by asking probing questions, we can collect actionable feedback that leads us to make worthwhile product improvements.

But only by asking the right questions, at the right time and in the right way, can this value be unlocked. If you need help learning to ask the right questions (and follow-up questions), this article is for you.

I have learned how to ask questions through a mixture of patience, practice, coaching, and building.

First, some relevant stories from my past missteps.

How my firsthand experiences building led me to ask different types of questions

When I started a FinTech company to help kids and parents learn about financial education at home, I asked parents if they thought financial education was important to the well being of their children.

What do you think these parents said? As a matter of fact, nearly 100% said that “yes” such education was important.

Guess how many of these parents went on to use the product I built? Only a fraction.

This short example illustrates the importance of asking the right questions. I asked the wrong one. Perhaps I should have asked the following:

• What tools do you use today to teach your children about financial education?
• Why do you value teaching your children about money?
• How are you planning to educate your children about money?

All three of these questions probe the same assumption as the first question: namely, that parents will want to teach their children about financial literacy.

But these questions are fundamentally better because they probe deeper and give the user room to explain their logic and rationale.

This qualitative feedback - where we can go deeper beyond assumptions and platitudes - is where insights exist to shape better product experiences. And that is a central goal for builders.

A second aim of builders is to not only build products that people use, but to build products that people find uniquely valuable.

When I was starting my career I had aspirations of being a Product Manager. A friend, who was a successful Senior Product Manager at Google, challenged me with a simple assignment: build a product that 10,000 people use.

I thought deeply about the challenge and looked into tools to help with student loans and Mapping APIs. Ultimately I decided that I would build a tool that helped solve various problems in my own life. I sat down and thought through these questions:

• What is a problem I currently have that technology can help address?
• Can I build a solution?
• Do I know how to build the technology?
• If I build a product, can others benefit from it too?

If you build it they may come...but you need to ask what your users want and need first.

I decided to build a Chrome extension that enabled users to quickly switch between tabs. After roughly 6 months on the Chrome store the free extension passed 10,000 active users.

I sat down with friends and started asking them how they used the tool and what they needed the tool to do to add more value in their lives.

I honed in by asking very specific questions:

• How many times do you use the tool (and I would cross reference this with internal data)?
• What does the tool not help you do that you need it to do?
• Can I join you at your workstation or desk and observe you using the tool?

These questions led to new insights.

Ultimately I decided that the improvements users wanted were beyond my technical capacity.

So I let the tool sustain itself without further coding improvements.

What did I learn from this experience?

Firstly, building is rewarding. Solving your own problems with small tools and hacks can be great fun and also educational.

Secondly, when you build something that has utility, and others start to use it, you have a unique opportunity to learn from users to make improvements.

These improvements, in turn, can yield even better product features, designs, and outcomes. These enhancements can better satisfy and align with the needs of your users.

Hence a small flywheel can be set in motion.

And lastly, it’s ok to build and push the limits without committing to further releases and development work. It’s ok to say “no” and allocate your time and technical resources elsewhere.

By asking the right questions you can unlock real value.

But this value does not need to be applied just to development cycles. It can also make you realize you are headed down a path you don’t want to be on.

And you can use insights from users - and gleaned from the questions that you ask - to make better informed decisions.

I had a product manager who once noted: “if the feedback is not a strong yes, then it's a no.” I think about this belief system a lot because I am always looking for perspectives that can help shape, inspire, and influence the products I design and build.

I would challenge that product manager - and you - to amend that quote: “If the feedback is not a strong yes, ask why not. If you can’t glean insights from users, then it’s a no.”

The art of intentional product feedback starts with you - the builder - and an open mind.

But tied closely to an open mindset is the ability to ask the right questions. It is healthy to say “in the spirit of open-mindedness, I’m striving to learn and I am learning by asking questions.”

There are many educational tools, online schools, engineering communities with online coding tests, and communities like freeCodeCamp to help you learn to engineer, design, wireframe, and deploy products.

But how many of these tools teach you how to ask questions, think critically about the replies, and then circle back with relevant follow up questions?

When building anything for others - a tool, a website, an app, or highly specialized software (like a QR Code Generator) - you need to know what people want, need, and most strongly value.

Only by asking questions can you learn these things. Only by asking questions can you produce a product that gets your users to a “strong yes.”

Suppose you have to add a new major feature to an app.

Is it easier to add this major feature to a relatively small app, still under construction and not yet in production? Or is it easier on a big app that has grown over time, whose overall quality is questionable, and which is already running in production serving several clients?

Well, there is no doubt. The second is a much more challenging task.

So then why do we usually find the most experienced developers, the architects – the "cool kids" – mostly involved in working on those smaller apps, while the rest of the folks are often buried in the large projects?

My story

Many years ago, I joined the dev team responsible for one of the core systems of a big corporation. The first position I was given was in the Application Maintenance (AM) team responsible for the legacy parts of the app.

The reasons were simple and were shared with me: I was new to the place, and new projects were running fast. They were using leading edge technologies for which there was not much experience. So AM was the right place for me to grow without too much pressure.

They told me that as soon as I had gathered enough knowledge and experience I would move to the Project team. This was the team developing new features with new technologies, the team of the experienced devs.

After one year or so this actually happened, but I will never forget that supposedly not-so-stressful period of AM.

The Project team and the AM team

All this was many years ago but, since then, I have seen the same pattern repeated many times, often in much more extreme forms.

When you have a new initiative, you start with the Project team. The Project team develops the architecture and the features. The Project team accumulates delays with respect to a very optimistic initial plan, and then they start working extra hours, cutting corners along the way.

Quality is often sacrificed to the altar of the Plan, tests are forgotten, and patches are added on top of patches. Developers start adding comments “To be refactored as soon as we have some time”. Technical debt is already there and it'll only grow.

Eventually the thing is brought to production and then, immediately after it goes live, the Project team starts the transition towards the AM team.

After some overlapping period, the AM team is left sailing alone. The AM team is usually younger, less experienced, and considered not as strong as the Project team.

But the tough part is over, the project is now live. Now it is AM time – it is easier, it has to cost less, and the company can afford a new junior team.

One year after the go live

Fast forward, and it has been one year of intense work. Bugs have been fixed, little things have been changed, and little things have been added.

The system has been eventually made ready to sustain a real production load and the codebase has grown. At this point the AM Team receives a request to add a new big feature.

And we are back to the initial question. Is it easier to add the new feature now or was it easier to add a new feature when we were in project mode?

The answer is clear: the task for the AM team is much more difficult. It is true that the AM team is sitting on their experience developed over time. But at the same time the AM team needs to deal with a not-very-stable code base, avoid introducing regressions without having a decent test safety net, and devise a way to deploy a new major version without creating disruption.

Let’s say it. The AM team often faces a much tougher job than the Project team. So why, if the task of the AM team is tougher, do all the experienced developers work in the Project team (and are now somewhere else, probably doing something else cool)?

A possible answer: the Project team needs to lay the right foundations

One reason to have the most experienced people starting a Project is that, at the beginning, we need to lay the foundations for what is to come. We need to define the architecture and make some fundamental decisions about the design of the solution, so the right experience is required.

At the same time though, at the beginning of a Project, we usually have only a limited knowledge of the problem we are called to solve.

At the start of any significant Project there are many known unknowns and also many unknown unknowns. For this reason, the Architecture of the system always has to be considered evolutionary. We need to be aware that many crucial decisions can not be made at the beginning but have to be made when the unknowns start to reveal themselves.

Architectural decisions can rarely be decided once for all at the beginning of a project. Critical architectural questions may pop up at any time in the life of the SW system. And those critical decisions made at the start of the project may have to be overhauled later – maybe because of new requirements, maybe because of new technologies like the Cloud, maybe because they were simply the wrong ones for the problem to solve.

So yes, it is true, the Project team has to make architectural decisions. But the AM also team has to make architectural decisions, and it has to make them in a much more complex environment.

You simply can not do the reverse

While the classical model of a strong Project team followed by a more junior AM team is not the most efficient in the medium term, the opposite is not an answer either.

Most companies can't imagine having a junior team starting a project and then transitioning it to a more senior team for maintenance. It's just not an option.

A case for subconsciousness

Maybe one profound reason why more senior people start new Projects with cool new technologies is that they like to start new things and play with new tech. But then over time, when the work seem to become more repetitive, they simply want to move on to other challenges.

This is good for their tech curiosity and this is good for their resume. But this is probably not good for the long term health of the SW system they are building.

From Project team to Product team

In 2006 Werner Vogels CTO at Amazon coined the famous “you build it, you run it” motto. It conveyed the idea that a team responsible for a Product needs to take care of it from its inception down to its run phase (where run covers both the Ops aspects as well as the evolution aspects).

To put it simply, the same team is responsible for all phases required for a Product to be successful: design, build, run, evolve.

This is the model adopted by the digital giants that have emerged in the last decade, from Amazon to Facebook to AirB&B. Their undisputed success is the proof that the model is the right one in the digital era.

Nowadays a growing number of people are emphasizing the need to move from a project-oriented way of organising work to a more product-oriented model.

This is a complex transformation which involves many aspects of an organisation. But for the topic we are debating here it definitely means that we need to abandon the idea of separate Project and AM teams and create more stable Product teams.

Product teams need to have the right mix of experienced people and more junior people who need to grow. Working together with the experienced devs, juniors gradually become experienced themselves. Controlled rotation is then possible without tampering the quality of the team.

Conclusion

In the era we are living, the Digital era, we should be suspicious when we hear something like “and when the Project ends we will transition to AM”.

This is not to say that there is no space for AM any more. There are still old legacy systems, usually serving the back office, which are egregiously doing their work, which are very stable, and which just need some Maintenance.

But when it comes time to develop new differentiating digital capabilities we need to move away from the Project/AM model and embrace a Product oriented model.

In this model, teams are designed to be responsible for building not only the first version of the Product they also run it. And they learn from running it while evolving it over time to make sure it remains relevant for its end users.

My partner Kevin and I have been working and talking about different side projects/startups for over 5 years. Two years ago we released our first product to the public, but it was one year ago that we decided to go full time on the indie hacker road. In this post, I’m going to explain our journey, our background and how we did it after many failed attempts.

This post is not about some magic product we launched in 2 days while getting 10k signups and reaching $20k MRR in one month while working 4 hours a week in Hawaï. This post is more about the small wins and loses we had during our first year in the Indie Hacker world, and the things we wish we knew before starting.

This post is about 3 products: one irrigation pivot, one startup pivot, and of course, some MRR.

(Disclaimer: ScrapingBee was initially launched as ScrapingNinja, but due to some copyright issues we had to quickly rebrand it. We'll talk about it in a future blog post.)

Background

It started when we were both employed in different startups as software developers. We had lots of ideas and we loved to build side-projects for fun.

Kevin and I were doing lots of Web Scraping in our jobs. Kevin worked at a Fintech startup called Fiduceo which was acquired by a big French bank, and they were doing bank account aggregation, like Mint.com in the US. He was leading a small team handling the web scraping code and infrastructure.

I worked in the US and then came back to France to work in the biggest French real-estate data provider as a data engineer. Part of my job was to find, gather, extract and load new data sets from the web.

So we both had experience with Web Scraping and data at scale.

Our first project: ShopToList

One of the first “mini-success” we had was Shoptolist.com, a B2C website/browser extension which is a universal wishlist that sends you alerts if it sees any price drop. It was really just a fun side project that was never meant to be more.

It allowed us to try many different things and to discover that acquisition is really, really, really hard. We quickly reached 1k users by just submitting our product on frugal/fashion subreddits. We were very happy about it because it was just an experiment.

Every day we had a script that scraped each product in our database to update its price, and we were sending an email in case of a price drop. The links in the email were affiliate links, so we took a small percentage if the user ended up buying the product.

In theory, this model works great, but in practice here is what happened:

• Out of 1000 emails sent, about 20–30% were opened
• 2% click on the product links that were on sale
• Out of this 2 %, 5–10% buy the product

The percentage we earned was very small, depending on the niche it was 0.5–5%, so this business model only works with millions of users.

And this is where we hit a wall, we did not manage to create sustainable growth. We tested many things, content marketing, affiliation, some paid advertising, but we just did not manage to create growth. And since it was just a little side project that only took us 2 weeks to build, we were ok with that.

For us, this was a very good experience, because this was the first project we really shipped to real users, and we learned a lot.

By digging into the database we noticed that a few users had thousands of products saved inside ShopToList. It seems strange unless they were crazy impulsive buyers, the majority of users had like 20 products saved on average…

So after a little “investigation”, we discovered that these users were E-commerce owners that were “spying” on their competitor…

Our first pivot: PricingBot

We assumed that those people were doing this to receive alerts when their competitor’s products were changing the price. There were many solutions on the web that allowed someone to do this, but ShopToList allowed them to monitor thousands of products for free when other solutions were quite expensive.

We did a small market research and discovered that many tools offered to monitor your competitor’s product, however, all those tools seemed either really difficult to use or really expensive.

Because we felt we could do better, the PricingBot idea was born. I quit my job and we both decided to commit full-time on this. Side project era was over ?.

We made a landing page explaining our value proposition, nothing fancy but something clear and nice enough so people could trust us. We got 60 signups from different E-commerce owners in different niches.

While technically challenging, extracting E-commerce product data was something we knew how to do thanks to ShopToList, so building the MVP was pretty quick.

We launched our beta on ProductHunt on November 2018 and it was a big success, followed by a big crash, the classic startup trough of sorrow.

ProductHunt launch

You had to upload a CSV file with your product catalog, and for each product match it with a competitor product URL.nIt’s ok for several dozens of products, but people had often hundreds or thousands of product in their online store.

So with this feedback, we created some integration with popular E-commerce platforms like Shopify and Woocommerce to let people import their catalog in one click.

Our activation tripled ? , we were very happy about how things were going. One thing to note, though, is that until this moment the product was completely free and we did not ask people for money.

At this point in time here are the few numbers we had that made use happy:

• We managed to have around 200 signups with $0 spent
• 20 users seemed to use the product and had their account fully set up

What could go wrong right?

We decide to close the beta and start asking our user to pay for our software with a classic SaaS model with three plans, $29/$99/$299 per month based on volume.

The first day was magic because literally several seconds after sending the email announcing the end of the beta we got our first customer for a $29 plan ?

We also managed to signup a $299 soon after, but for him, we had to manually set up his account and manually match 1000 products across 10 websites. It was long but we felt it was worth it. We were wrong! Just before renewing he churned telling us PricingBot was very good but not useful enough for him. We were sad and angry, mostly at ourselves, but decided to move forward and continue.

It seemed we were on a good path and that we just needed to go all-in on marketing. And that’s what we did. Content marketing, cold outreach, affiliation, SEO you name it!

But before diving into this, let’s talk again about our activation

Mistake #1: bad metrics leads to bad conclusion, bad conclusion leads to bad decisions (in Yoda’s voice)

When we first decided to monitor our activation rate we assumed that one user was activated when he did two things:

• Add at least one of his product, (or link his store with our built-in integration)
• Add at least one of his competitor’s product

And so, with that definition, we had around 10% of our users that were “activated”. Considering that at that time most of our users were coming from ProductHunt and that hunters are known to easily signup to products they don’t plan to use and just for the sake of it we were happy with these numbers.

But we were wrong.

This definition meant that someone who owns a Shopify store with 4000 products, and who adds only one competitor’s product, was activated. This was silly. Someone who only adds one competitor’s product out of 4000 of is own catalog won’t use PricingBot to do price monitoring and surely won’t pay for it. We learned this the hard way.

Because soon after we had this first paying customer, nobody followed, literally nobody. At first, we did not understand. Then it was obvious: out of 200 signups, we had 20 active users, out of 20 active users we had 1 paying customers, so the only solutions were to have more signups.

This was another mistake.

Mistake #2: Thinking our only problem was acquisition

We thought we only needed more users and just went full marketing. Because we did not know the e-commerce community very well we had some trouble starting. But we eventually managed to write some piece of content that was shared on relevant Facebook/Reddit/LinkedIn group that brought in a few leads.

We also did some paid advertising and cold outreach but it failed miserably.

One month later, we needed to see the obvious: we were not on the right path.

Our leads used the product but did not pay, and even if all the leads we brought in paid, it would have not been sustainable.

At this point in time we finally decide to understand better why users don’t use our product more and with feedback request and lots of analytics insight we discover two things:

• For most of our users, PricingBot was a nice to have, but it was not something worth paying for
• Most of our users didn't want to do the setup because it is too tedious, but they didn't want to pay us to do it for them.

Next thing we knew we revamped our whole onboarding process and try to automate as much as possible. But it was still not working.

When you want, as an e-commerce owner, to monitor your competitors, you first have to link your products with your competitors - and this was the hard part. This part alone meant approximately 1 hour of work per 100 products you want to match. This was way too much time for an e-commerce owner working alone with a 10k products catalog.

Fear, Uncertainty, and Doubt

To help you understand how we felt at that point in time let me just recap the timeline:

• January 2018: ? we launch ShopToList
• July 2018: ? I quit my job and we decide to build PricingBot
• October 2018: ? After a busy summer and 1 month of code we launch the MVP in beta
• January 2019: ? First paying customer
• February-March 2019: Acquisition, product dev

Back in May 2019 we kind of hit a wall. Nothing we did really worked and it was hard staying motivated. The only silver lining was that we managed to rank well on Google so we had, every day, around 3 new signups without any acquisition.

But we still did not manage to make them pay. And we still did not manage to make them configure their account.

This period of time was hard because it was full of negativity. My cofounder and I both knew that we were not moving forward. While this did not degrade our working relationship, it certainly degraded our working productivity.

We both felt that no matter what we did, we were not able to move any meaningful needle that could have boosted our business.

We improved the product a lot, managed to gather some signups along the way but it was not enough. Here is a look at our revenue.

One agricultural pivot to build, one startup pivot to make

Mid-June 2019 things are not looking good, we only have 3 months to launch a successful business. We both agreed in 2018 that we gave ourselves 1 year to launch something that worked, 1 year to reach “ramen profitability” ?.

We had a long talk beginning of June and we both agreed that we needed to step back. We currently had 3 options:

1. Continue with PricingBot hoping that some magic happens and that we cross 4k MRR in 3 months
2. Leaving the company and start going our own way
3. Building something else

Point 1 was hard because we were both fed up with the product. Everything we did seemed useless and it was not working. Point 2 needed to be addressed, but although it was not a success we felt that working together was working really well (in the human side of things). It would be a pity to give up.

But we chose option 3, and we are both very happy with the outcome of that talk and full of energy. We only needed one thing: to choose what we would build.

We also decide to do something we should have done earlier, we sold ShopToList. The whole deal was done in less than 1 month thanks to 1kprojects.com and it brought some welcomed money in our company bank account.

In the same time, my father in law, a farmer in the south of France called because he needed help assembling an irrigation pivot. The heatwave was supposed to be hard in June (and guess what, it was), and it was an urgent job. We both decided that this was a good opportunity to take a break, to think, each on our side, about the future product, and to come back full of ideas and motivation.

It was kind of ironic because this pivot kind of funded our pivot.

Disclaimer: If you ever need to buy an irrigation pivot I strongly suggest that you look into Valley pivot (PS: this post was not sponsored by Valley in any way)

ScrapingBee

Two weeks later, we both found ourselves with a bullet list of product ideas, some good, some bad, some crazy, some boring, some exciting, well, you get the idea. Both lists were diverse. However we quickly agreed on one idea, because it really stood out from the others. Let me explain.

While working on Shoptolist and Pricingbot, and also in our previous work experience, there were three things that we always needed to do for our web scraping infrastructure:

• Transforming websites into a structured API,
• Running headless browsers at scale,
• and managing a pool of proxies.

When you extract data from lots of different websites, you always have to deal with Javascript-heavy websites / Single Page application, and you don’t really have other choices than running headless browsers to render all this Javascript.

Running a headless browser like Chrome is really painful because the same thing happening on your desktop (high memory usage, poorly coded Single page application eating 100% of your CPU) will happen on your servers. So it is not only painful but very expensive to do this on your own when you don’t know what you are doing.

When doing web scraping at scale, you often have to use proxies for different reasons. The website you are visiting with your bot may show different information based on your location - for example, a price in Euro in the Euro-zone and a price in dollars in the US.

Dealing with proxies is painful too. There are lots of shady companies selling bad quality proxies so you either have to run your own proxies or test dozens of proxy companies to make sure your proxy pool is always up.

We used to solve all those problems using APIs that were either not really efficient or crazy expensive. These are problems that we solve multiple times in our projects so we thought about packaging it into an API and leveraging our experience to make all kinds of web scraping APIs.

We decided this time, to make things right and to try to avoid doing the mistakes we made with PricingBot while creating ScrapingBee.

Mistake avoided #1: creating a product you won’t use

One of the biggest problems we had with PricingBot was to find where our potential users gathered online. What group did they follow, what blog did they read, what influencers did they listen to. And the reason was simple, having never worked with or in the e-commerce industry except for some freelancing gigs, the whole landscape was unknown to us.

With ScrapingBee we would be our own users and it changed everything. I know this advice is not new, but often this advice is meant to build a better product. And sure, being one of your own users allows you to build a better product.

But for us, the game-changing fact was that being our own users meant that we knew exactly where to find and how to reach potentials leads.

Kevin and I also have our own blogs running for quite a bit of time and I wrote last year a book dedicated to web scraping in Java. This directly translated into 20k monthly visits that we could leverage to promote ScrapingBee.

And it worked. In about 2 months, we reached 150 beta signup, 4 times the amount of beta testers we had for PricingBot.

Mistake avoided #2: Spending too much money

While building PricingBot, we spent a lot of money on useless infrastructure, APIs and software without reaching Product-Market Fit.

We got to get our money back thanks to ShopToList sale and my agricultural skills before we launched ScrapingBee, but this time, we were way more careful about how we spent it.

I know spending several thousand dollars to bootstrap a project is not a lot of money but we weren’t comfortable with spending more. So we decided to be careful with how we would spend it with ScrapingBee.

We basically reduced our costs by only finding deals (❤ AWS Credits) like Secret which basically give you 6 months free for lots of SaaS or a huge discount.

We decided to do more with what we had, and so far we don’t regret it.

I’ll talk more about products and tools we used in a future blog post, this one is already long enough.

? Launch ? and mistake avoided #3: not asking for money from day one

One thing that did not work well with PricingBot is that for months, we built a product that was free to use. I know this is a classic mistake, but this is not the worst part. The worst part is that we knew it was a mistake. In the last 4 years, we’ve read tons of books, interview, blog posts about startup and everyone seems to agree that the sooner you ask for money the better.

But it was easier said than done and we did not dare ask for money while building PricingBo. We just did not think anyone would pay for an unfinished product.

We did for ScrapingBee. The pricing for ScrapingBee is again a classic three plan SaaS based on API call volume/feature starting at $9 / $29 / $99 per month and an Enterprise plan.

We “soft-launched” first to our mailing list and got our first few small paying customers. Again, we had the same experience with PricingBot but this time it was different. With PricingBot, every paying customer we had was really hard to get, we had sent them tons and tons of email and they took a long time to finally pay.

With ScrapingBee it was different. Our first 2 customers had never talked with us before.

We then started to blog and got tons of leads along with a few more paying customers including a big Enterprise plan as you can see in the MRR chart below.

Then it all went quickly, Kevin and I both having blogged about programming, creating insightful content about Web scraping is not a problem for us, and we knew how and where to promote it.

One particular piece of content we wrote, a web scraping guide completely exceed our expectations.

This post alone meant that in 2 months we had 3 times the traffic we had in one year of PricingBot. This post not only brought traffic but also customers with real $. It also allowed us to signup the first big enterprise plan that allowed us to reach and cross $1000 MRR.

The future

Of course, it’s really early to say if ScrapingBee will be a success or not.

This big enterprise customers thanks to the success of our first blog post could only be an outlier phenomenon that won’t reproduce in the future. Maybe it will. But one thing is certain, things are looking way better with ScrapingBee.

We have lots of engagement from our users and leads, the conversion rate from trial to paying customer being close to 5%.

We also love to talk with our potential customers (❤️ Zoom) and we have the feeling that ScrapingBee is really a must-have for them, instead of a “nice to have”. (small tips: we offer 10 000 free API credits for users that accept to have a small 15 minutes talk with us, this already allowed us to have 50 real conversations with real people about ScrapingBee)

In-app message to incentivize users to schedule a call with us.

In the months to come a big challenge will be to find profitable and scalable acquisition channels. We hope that content marketing will continue to work and that it will improve our SEO to get organic traffic. Writing a good piece of content may not be enough and we really have to discover other acquisition channels.

The other big challenge is to prioritize features in the API-store. Meaning figuring out what users need not blindly implementing what they want, and hopefully, manage to get them to pay before the feature is implemented.

We still don’t know what we want to do with PricingBot, we seriously think about selling it but are a bit afraid of all the paperwork involved (it was much easier with ShopToList because ShopToList did not bring any money in, so no bank account, Stripe account, etc…)

We also still have a lot to learn and a lot to prove before being able to say that we build a sustainable and profitable business but for the first time in our lives, we feel that it can be done, time will tell us if we’re right.

I really hope you liked our little story and that your learned some interesting bits along the way. We plan to do this kind of posts every 3 months at least, please tell me if you'd like to read the next one ;).

Innovation is difficult.

To empower innovation and transform how teams work, you need the right mix of culture, technology, processes and inspiration — and this takes time. Typically, it requires an ambitious, long-term transformation programme.

In the context of software business, this program could face additional challenges. As engineers focus heavily on technical excellence — which is great — they frequently find themselves disconnected from the commercial world or the end-users of their products.

To become truly innovative, engineering teams need to also capture the ‘big picture’ and fully understand the purpose and the commercial aspects of the business.

Novelty, innovation and success could all mean different things and have various priorities in an engineering team. This means that you need to adjust your innovation strategy, communication style, and tactics.

1. Define ‘Innovation’

In the corporate world, innovation could be anything novel that creates value for its users and has potential for commercial success.

Innovation could be incremental or breakthrough. It can happen at any time, such as following a ‘call to innovate’ like a hackathon or design sprint, or randomly — driven by original ideas, genuine talent and inspiration.

Innovative thinking typically leads to ideas and concepts regarding products or product features. In an engineering context, the outcome of innovation may also take other forms — from abstract technical concepts, patents, algorithms, data models to architecture patterns and functional prototypes.

It can also trigger process improvements. For instance, novel ways and tools to speed up your overall development lifecycle and boost DevOps KPIs.

Engineers as innovation leaders

In many cases, software engineers innovate ‘silently’, inside their own microcosm. This can be at a lower level (the actual design and implementation) or at a higher level (components and system’s architecture).

But, engineers can play a more important role in leading innovation.

In fact, they have a great advantage in driving innovation efforts. They are the ones with deep understanding of technology and they are often passionate about it. This allows engineers to easily spot both the opportunities and the underlying constraints of technology.

Moreover, engineers are expected to understand the principles of experimentation and be ready to take risks following a ‘fail fast, fail-safe’ approach.

Either as part of wider multidisciplinary team or as an independent software development unit, skillful engineers can thrive in leading real innovation, beyond the hype. What is needed is the right culture and steering — the key signals and a clear direction from the leadership.

2. Empower Innovation

Set the right context

The culture in engineering teams is special. Engineers tend to have limited engagement with over-hyped business terms and marketing buzzwords — and innovation is one of them.

To change that perception, engineering leaders need to define innovation in the context of the company and with the right language for the team.

The discussion on innovation must be supported by solid definitions, examples, programs and tools. Teams need to relate to innovation success stories — and understand what ‘innovation success’ means in their specific setup.

Examples and references could come from the public domain, or ideally from the recent history of the company.

Establish the right culture

Engineers need to see themselves as innovators, creators, and builders. They need to realize that they don’t just implement a feature, a component or a process in isolation. They are part of something bigger which typically drives significant financial value, or other important corporate KPIs.

As an engineering leader, you need to encourage teams and fellow engineers to share their ideas and thoughts. But not only in their domain of expertise — literally on anything in your business reality. And you need the mechanisms to capture these thoughts and enable effective discovery and collaboration scenarios.

Your engineers need to feel trusted, also in terms of time and focus. They need to have some autonomy on when and how to pursue their ideas. And this is where you need a strategy and a framework to ensure that you maintain the right balance between productivity and ‘dreaming’.

Having productivity baselines along with metrics on innovation activity can help you monitor, understand and steer the innovation efforts.

Depending on the current workload and velocity of the team, you can set the appropriate balance between productivity and innovation. For example, by de-prioritizing innovation-related work/ideas or reducing the frequency of ideation sessions.

Technology can provide great support here. Intelligent ideation platforms can easily capture and automatically handle ideas, thoughts, problem statements and even connect this innovation stream to your product backlog with relevance and intelligent prioritization.

Invest in technology

Modern teams need an always-on channel for ideation and collaboration — which could also get connected to your engineering processes.

Imagine if your product’s backlog entries were seamlessly matched with incoming ideas. Or, if ideas were automatically scored against backlog relevance, or having an intelligent process that groups and summarises all known-issues, bugs, performance limitations, system constraints, negative user feedback etc. as well-defined, prioritized ‘problems to be solved’.

Innovators from within your team or across the organization could discover relevant-to-them content and respond with novel ideas on potential improvements and fixes, or innovative ways to solve the problems stated.

Enable rapid prototyping and experimentation

Failure is part of the overall innovation process — as soon as it is fast and safe, it provides important learning opportunities through insights and findings.

Following practices like ‘rapid prototyping’ and ‘fail fast’, ideas can be quickly tested with real users, to support informed decisions, as early as possible and at minimum cost.

Rapid prototyping is also a key principle: in contrast to the ‘production mode’ where engineers need to follow certain processes, coding principles and protocols, ‘rapid mode’ allows engineers to use shortcuts, make assumptions, hard-code if necessary and use artificial data to quickly build functional instances of an idea. This rapid mode, focuses on building prototypes, that can be exposed to selected users and capture feedback towards possible next steps in the development process.

‘Rapid prototyping’ requires both ‘a different mode of operation’ for your developers, but also the right technology readiness. You need to maintain, reusable components, APIs, UI elements, standardized data sets and other assets, to enable quick assembly of realistic, functional prototypes, without wasting effort on functionality which is not directly relevant to the core idea — the one to be tested or validated.

3. Measure Innovation

Quantifying innovation is difficult. Measuring innovation activity is easier. You need to introduce a framework to capture events which are relevant to innovation — this could be ideation, contribution to ideas, prototyping efforts, patent filing etc. Having a rich, reliable history of such activity is fundamental in defining related baselines and reference points. Innovation activity metrics could then be linked to certain KPIs and analysed against product and financial performance.

Qualitative assessment regarding the overall innovation performance within your team and the entire corporation can also be very useful. As an additional set of innovation indicators, domain experts could assess the novelty and level of innovation in specific deliverables or product releases, against the corresponding state of the art.

All the above could be linked and presented in a solid Innovation Performance dashboard for both management purposes and for achieving a general awareness related to innovation performance.

As published in ‘Perspectives in Engineering’ by GitPrime

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.

Moving from a concept to a properly defined MVP

The Minimum Viable Product, although a properly defined term, means different things to different people. In fact, it is one of the most misused terms in the technology domain. It is often poorly referenced to describe a prototype, a demo or even the first deliverable of a project.

“In product development, the minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future development” — Minimum_viable_product

Defining the MVP

Assuming you have this great idea, you need a method to start defining the product. More specifically, the subset of the product features that can serve your objectives with the minimum cost and risk. The following explains how to get from an idea to an MVP.

Identify your users

Set the context — think of the problem, the situation and the opportunity. Think of what is already available in the market dealing with the same problem. Identify and name the types of users involved and how they interact. Document your users, their needs, the problems they are experiencing, their expectations, and the best-possible experience they could have in your context.

The Minimum in the MVP implies that you already have the big picture, you have the product vision! A common mistake is when the team ‘easily’ identifies a set of ‘obvious’ use cases as the MVP — without a clear product vision and the big picture.

Check also: How (and why) to write great User Stories

Think as a user

Having the big picture you need to apply a process to identify the smallest subset of functionality that serves a very specific goal. The goal is to satisfy your users. You also want to enable critical user insights and feedback. This feedback can improve the next iteration in your product development plan.

The big picture is the super-set of user stories across all the classes of users identified. It’s a good idea to create a large set of epic stories. Then iterate across all identified users and try to define user stories covering their needs and expected benefit/ gains.

Use a compact format as the one proposed in Scrum: as a I want to so that <describe the gain>. You don’t have to worry about priorities at this stage. A good idea would be to name each story/ assign a compact title for easier classification and organization.

As soon as you have your product feature super-set, you need to review it to ensure that it defines a product (the P of the MVP). Search for continuity, homogeneity and complementarity among your user stories.

As a result of this process, you may realize that more than one of the related products are referenced in your backlog and need to be separated. Or you may realize that there are significant gaps that need to be filled.

Again, think as a user. Use empathy to identify interactions, scenarios and stories that need to be included.

You need to also gather feedback so you can try to validate your stories and the product. You can gather feedback through expert advice, user interviews, formal or informal surveys or public domain references (for instance any reliable public domain statistics that can help you test your assumptions).

Think as an entrepreneur

Thinking as a user is great. You can be creative and forget, for a moment, about real-world challenges such as technical and financial constraints. Your objective is to compile the product super-set of user stories to satisfy — or to even to excite — all the different types of your users.

Now it’s time to think as an entrepreneur. You need to start considering and documenting implementation costs, priorities, strategic advantages and differentiators against competition.

You need to estimate the development cost of each user story. You also have to quantify the expected value for the user along with the expected impact on the business: your business.

The logic to identify the right minimum subset can be complex — requiring estimates of all the above at the user-story level. For each user story (or Epic) you need to have at least the following:

1. The complexity / cost associated / feasibility

2. The expected value for the user

Estimates of the above dimensions could be on a numerical or ordinal scale. As soon as you have those estimations you can then rank your stories. Also plot them in a simple chart against complexity and expected value for the user.

Check also: How to become a great Product Manager

Prioritize, Rank, Set the focus

At this point you can start prioritizing high-value, low-cost stories over lower value, costly ones. Be aware, though, of those natural, strong dependencies between product features.

In many cases there are technical or procedural dependencies requiring certain features to be implemented first, although their cost is high and the expected user value low. These dependencies need to be identified and possibly visualized in the user stories mapping.

Having the above for each of the features (user stories) of your product allows you to define your MVP as:

“… the minimum set of features (stories) ensuring a good-enough product experience driving increased user engagement that can secure the next product development cycle”

You can sort your entire product backlog by dependency sequence (start with foundation). Then by the value for the user in descending order. Then by complexity and feasibility in ascending.

You can also combine budget constraints, team’s velocity and go-to-market strategy makes it ‘easy’ to identify the red-line of your to-be-proved Viable MP.

Reality check

In reality though, this will be just a draft definition of an MVP. What is needed in an ideal scenario is feedback and validation of the features by real users via prototyping, focus groups, market research, competition analysis and related methods.

The more input from real users, the more confident you can be that your product concept has all it takes to become Viable (which also assumes a great execution/ implementation/ launch).

Check out this other article on how to define an MVP (among other things).

Thanks for reading!

Images: pixabay