Feedback Loops: Build Faster and Better

Ready, set, go!

When you're trying to grow your business, time is of the essence. Companies must remain relevant, keep up with current trends and satisfy customer needs to stay competitive. But how can they move quickly without sacrificing quality?

If you’re asking yourself such questions, then look no further! The secret is customer feedback!

As a business owner or product developer, this will come as no surprise to you. Customer feedback is critical in all steps of creating a business. After all, what's the point of putting in all of this effort if no one wants your product?

Why is feedback important 🤔

Another excellent question! Many of you might have heard the expression "the customer doesn't know what they want". So why even bother listening to what they have to say? Even Henry Ford once shared:

If I'd asked customers what they wanted, they would have told me, 'A faster horse!'

Well… extracting these quotes without providing context can be very deceitful. You don't make an innovative and ground-breaking product by asking people what they need. If people knew that, then there would be no problem to solve!!!

You do it by identifying the problems people have and creating an elegant and approachable solution. And this is the hard part! You need to understand your customer's needs, jobs to be done, pain points, what they like, what they don't like... Then and only then can you truly meet your customer's needs. This level of understanding removes the need for guesswork and provides a clear leeway for product development. It gives you confidence that the solution you're building will be not simply used but loved!

If your business is in its early stages, pay extra attention!! Customer feedback is even more crucial early on. Why? Because it’s much easier and less expensive to make changes to a product before it has been publicly released. You want to catch your mistakes and form your core product ASAP. Otherwise, you’d be wasting all your hard efforts by pivoting your business late into its development.

Lastly, actively listening and engaging with your customers builds a sense of community around your product. Such a community yields many benefits, one of which is quickly extracting feedback. For those interested, we have a whole article about how we build a community around our product.

How we gather good feedback 🧺

Now that you know why feedback is so important, it is time to understand how to gather it effectively. This can be tricky. Not all feedback is created equal - there's good feedback, which can propel forward momentum, and bad feedback, which can derail progress if it isn't handled correctly. At Userled, we do our best to do the groundwork necessary before we start building features, so we end up with the former kind of feedback.

So the question begs: How do you gather feedback that you can act upon?

We considered most of the bread-and-butter tools you hear about - customer surveys, user interviews, etc. but we found those slow and unreliable. These also tend to be useful after you have built the product, by which time it may be too late. As we’re a small team and most of our time and resources are focused on product development, we need to adapt.

That doesn’t mean we don’t collect feedback and talk to our users. Instead, we do so in a continuous manner and embed the feedback loops into our development cycles.

👇 Lets dive a bit deeper into our processes. 👇

0. It all starts with an idea or a user pain point

The idea can come from our users or internally from the team.

We follow an RFC approach to solution design. However, rather than writing these solely for engineers, they target technical and business stakeholders. We use the RFC format to provide context around the idea and user pain points. Then we scope out product requirements, identify the assumptions made and suggest potential solutions listing constraints and desired (measurable) outcomes.

Great, let’s build. NO! 😡

1. Validate your ideas and assumptions with the help of domain experts

The primary goal of this step is to validate assumptions and reduce uncertainty.

We have hand-picked a team of domain experts who help guide us through our ideas and assumptions in areas where we lack experience:

• Business applications expert: An expert in B2B SaaS products that helps us understand the mindset of SaaS customers.
• Product leader: We’re not product managers by trade, so we get guidance on the do’s and don’ts of product development, roadmap planning, etc.
• PLG expert: We are a product-led organisation and so are many of our customers. This person helps us understand what that means for ourselves and how best to serve product-led customers.
• Revenue leader: Revenue and Growth leaders are our target personas. Our community is full of them. There, we can bounce ideas and quickly validate assumptions around their pain points, jobs to be done, and much more.
• Startup founders: Helps us learn how they approach building at speed.
• Engineering guru: If we have knowledge gaps or uncertainty around engineering solutions, they’ll help guide us in the right direction.

Each of these domain experts is either a Slack, Whatsapp or Email away to help us.

We’re never 100% certain and if we’re below a certain threshold, we won’t prioritise an idea. We believe 70% confidence in an idea and solution is a good rule of thumb. However, that depends on whether it’s a small feature or a big bet.

Also, trust your gut! 💪

2. Follow a Design-Led approach

If a particular idea is a big bet or requires a sizeable engineering effort, we tend to prototype it first using Figma. This gives our users and us a visual representation of the tool they can interact with.

Then if we’re still happy with it, we showcase it to our community. After all, who better to ask for feedback than the very people using the product? This provides us with confidence in our designs before even starting the development progress.

3. Define your criteria for success

How do you measure the success of what you’ve built? Well, we created another RFC that describes desired outcomes. We make sure that desired outcomes always reference our North Star Metric (NSM) and some core business KPI(s). If the idea and its solution don’t appear to impact those in any measurable way, then we’ll reconsider.

If we’re missing any metrics and analytics around these desired outcomes, then we ensure to build these before implementing our solution.

Amazing, we have an idea of what success looks like and how to measure it. Now we can build. 😌

4. Prototype and Build

Depending on the implementation cost, we may decide to deliver the solution in one go or spread across multiple iterations. The rule of thumb is to build features end-to-end and focus on small deliverables which still impact the user. For this, we use the 70% approach once again - get to the 70% milestone, validate the idea’s value and finally polish, polish, polish.

Phew. You’ve built and delivered it to your users. Time to celebrate 🍻

5. Measure, learn and iterate

It’s all running smoothly. Now you can measure usage and learn from it. We have a simple but mature product stack that helps us keep track of user activity in our product. For those interested, we wrote about it here.

The broader questions we aim to answer are:

• Are people interacting with the feature or product?
• How often do they use it?
• How are they adopting it in their daily activities?
• Are they getting the value we expected?

Based on the results, we can keep the feature, optimise it, expand it, pivot slightly or completely retire it. We can measure success over days, weeks and/or even months.

Closing words

Now, you may be thinking, “Martin, this is crazy!” or  “It takes way too long!”. Yes, there’s for sure a learning curve to getting this right - it takes practice. But we go slow to speed up after. And as you get more comfortable with this process it’ll become second nature. Keep in mind that we don’t run this process for every idea but rather for the big bets or features with a high cost regarding time and resources.

Although this article mainly focuses on external channels for feedback, it is essential to note that internal evaluation is as critical. For that, we heavily rely on Demo-Driven Development (DDD). For more info, you can check out our blog.

‍