The customer is not always right - AMA w/ CEO of atono
Hey all - Troy McAlpin, CEO and co-founder of atono here.
In our last $70M ARR SaaS venture, we learned the hard way: the customer is not always right.
Yes, customer experience matters. Yes, they’re the ones paying the bills.
But no, they don’t always know how to design the best solution.
Steve Jobs famously said, “Customers often don’t know what they want until you show them.”
At @Atono, we’ve taken a stand. We may lose some potential customers along the way (who would have churned), but we believe it’s the right answer. Customer preferences and vision don’t always align with your product’s 3-7 year roadmap.
A few thoughts on customer feedback:
Listen intently and be grateful for feedback, but dig deeper to understand the pain.
Build solutions that address real pain, but stay within your through-line.
Avoid being all things to all people - it’s a very real competitive disadvantage.
Opinionated software development recognizes multiple competitors can thrive in a market. It drives differentiation and embraces a growth mindset over a closed one.
We’ve learned this through years of experimentation, failure and success - happy to share! AMA
Replies
Can you provide some specific examples of this approach when it comes to your @Atono launch?
@chrismessina Hi Chris - for sure. I can share a few from our Pre-GA and beta discussions with prospects:
Stories or issues: Some customers of other applications are familiar with each unit of work being an issue and using tags and labels for everything. We developed higher class object types (like stories & bugs). We fully acknowledge some want a bucket of issues, however our opinion is that treating objects uniquely allows us to make the product more intuitive and reduce cognitive load.
Rigid bug triage: Beta customers asked for a customizable bug triage capability versus our "best practice" approach of rating bugs by impact x likelihood. I am air quoting "best practice" because it's opinion. This was a tempting areas to allow configuration; however what's important about triage is consistency and timeliness over bespoke process. We may choose to readdress this in the future but for GA this was a drift from our through-line.
Oh we'd buy it if... you support premise installs or government hosting. Several prospective customers (using the industry's most popular application) asked for specific support that wasn't in our through-line. Previously we chased "dollars" - these early exceptions do not make markets. It's hard to say no, but no is the right answer. Our experience tells us chasing these potential sales permanently reduces our feature velocity.
Customers matter more than the product because a great product is useless if no one wants to use it.
Unlike Steve Jobs’ vision, most of our businesses don’t create revolutionary products overnight.
Instead of forcing a product on customers, we should listen to their needs, solve real problems, and adapt.
Happy customers bring loyalty and growth. Even the best product fails if it doesn’t fit the market.
@kankipati_arun I agree whole-heartedly that happy customers are what matters. The value of a "referral" from a happy customer is greatly undervalued in B2B. I study companies like Zappos, Nordstrom, Disney and others to learn from and model the approach of providing an outstanding service experience.
It doesn't have to be "or" however - customers matter more - or - your product vision matters more - it can be "and" or both.
I agree that most SaaS products today are evolutionary, not revolutionary. That should not be used as an excuse however for building products that are just incrementally better than a predecessor. In my experience, that approach does not achieve the first objective of a "happy customer".
In my experience, asking questions of customers to discover real pain, then designing the solution within the long term vision you are orchestrating helps product teams avoid drift and building products that are too confusing, trying to be everything to everyone. It's a big world out there so it's ok for a product to not be the right answer for every customer.
@troy_mcalpin1 I totally understand your point of view that Customer & Product <> Both are important, that's exactly my point too as an Old school guy I look at necessity being the mother of invention, but at times this notion has been thrown out of window.
Anyways all the very best for your organization!!!
@kankipati_arun and to yours!
Metabase
Interesting take! Agree that often we put too much onus on the customer to tell us exactly what they need vs. deeply understanding their problem and coming up with creative solutions for them. I'm especially interested in your point about listening intently and digging deeper to understand that pain point - how has this impacted the type of conversations you're having with customers? And how has it changed your approach to problem solving and building your roadmap?
Hi @jessillions
In our experience, when you ask lots of sincere questions and actively listen, you build trust with the customer. The impression they feel is "oh they are a partner, trying to help" not "CTO-splainen" a solution).
If a customer pushes to build something specific that is not on our through line, we sincerely listen and empathize with the need - but then we open up and share deeper strategic plans with them - often the customer finds this even more compelling and is willing to agree with the roadmap over the feature.
Many times the one-off, specific requests result in another UI element (or menu-diving) that is innocuous, however cumulatively it could lead to a complicated, confusing user experience. We find ourselves continuously reminding ourselves and our customers that the simple, intuitive, relaxed user experience is a strategic priority and requires some discipline to stay true to that vision.
We track requests, as you probably do too, so if we receive repeated requests for things that are not strategic (in our opinion) we may thoughtfully and carefully reconsider our conviction.
Hello! Thanks for sharing your insight.
Your post reminds me of advice from my mentor entrepreneur. He once said, “You think customers are always right? Well, they’re not always. And you think YOU’re doing customer interviews right? Even YOU might be doing them wrong.” His words really stuck with me and made me realize the importance of a founder having a firm vision of their product. Without a firm grasp on the vision, it’s easy to be pulled in every direction by customer demands, and the service might end up losing its identity altogether.
I think I found the answer to the question -"How to do customer interviews right" - from your post and comments. Asking customers sincere questions, building trust with them, identifying deeper problems seem to be the key points.
But I’d like to question you about this. I believe balancing the founder's own vision with customer feedback is crucial. How do you identify when it’s time to put aside your original vision and pivot based on customer input? Conversely, what signs indicate that it’s critical to hold firm to the vision? Are there specific indicators or signals you personally look for in each scenario?
@hyuntak_lee You bring up a good point of forgetting to validate your vision, or not be so stubborn that you miss the market, chasing your personal dream. I don't know that there is a hard and fast proven method for measuring when to pivot - but I would suggest carefully analysis and measurement should be applied before pivoting (previously I chased $s using the next sale as validation, which was a very expensive lesson to learn).
Low cost testing of your short-term (0-36 months) hypothesis: Your vision does not always equal current or future market demand -- so testing the problem statement and suggested approach -- with inexpensive validation (inexpensive = no coding) -- is where I would start. This should be done through interviews, survey's, posts on forums (e.g., here, reddit, etc.). You can use mocks of course to help validate your path to address the pain, that's another round of interviews and validation. If it's valid move on, if not repeat this step until you find pain people will pay to fix (and reasonably it applies to many or all - not one bespoke customer).
Expose your vision (36-60 months) and validate your assumptions: If you believe there is a shift coming in the market, validate that assumption. If you believe the problem will get worse with time, validate that assumption. Once those long term assumptions are validated you can form your vision and start building.
Get users in the product as soon as possible: We used focus groups, mock product, etc. while building then as soon as we had something functional we got people into atono. We found blind spots that we missed, validated against our vision for the product and changed what was in our through-line. We ran alpha, beta and used the product for our productive use to validate it (even though we are biased). We also went to places we know are unfriendly for our approach to seek objections early.
Onboard ICPs and start the flywheel turning: In this statement I'm suggestion you identify your ICP, test it, produce content for the ICP, meet them where they are (events), and validate the ICP. Once you believe it's a population large enough for your initial go to market then launch, get the first few on board, provide them amazing service and ask them to refer a friend. The first five are harder than number 100-105. Getting the flywheel turning takes effort.
Throughout this effort take a humble approach, seek criticism (treat it like a gift), and keep experimenting and validating. When your experiments fail or you can't nail the items above, pivot. But don't give up.
You can't win a race you quit, ever.
@troy_mcalpin1 I'm so grateful to have your reply this specific! It feels as if having a personal consultation. Thank you so much for your time and effort to write the comment.
The iteration of experimenting and validating is the key, as I understood.
And another crucial point I'm learning from your comment is the attitude to criticism. I'll treat them like a gift, as you said.
Thanks again for sharing your precious insight. You taught me a lot with your comment!
@rashed2 You hit the nail on the head, those frankenstein monsters often end up being classified as "enterprise" software - trying to be everything to everyone - in some cases they become their own ecosystems or industries just to service the applications (a few come to mind like Jira, Salesforce and Service-now) - all very successful, but also bloated and complicated. I learned from a friend that left Atlassian that the feature velocity he experienced as a developer on the JIRA team was one - one feature, in one year...sadness.
Completely agree, @troy_mcalpin1. As a company/problem solver, your job is to understand the needs and pain points of the customers but do not ask them (or listen to them) for a solution. Building an innovative solution that addresses customers' needs and pain points is the company's responsibility.
That's why I love Jobs to be Done framework that tries to unravel the underlying needs and desires of the users. Don't ask customers what they want (the solution), ask them what problem they are trying to solve.