RevFixr's early customers asked for pricing help before installing its SaaS. Helping them choose what to charge was a different job from helping them set up a pricing page.
Its founder, Tjitte Joosten, had built software for businesses' pricing pages. He described the requests this way:
our early customers kept asking for pricing support before installing our product.
I would put the weight on "before installing." If you treat that request as an onboarding problem, making the software easier to adopt looks like the next task. A product could help with that decision, but easier installation alone doesn't settle it.
Joosten says the team began offering pricing-strategy support as a paid service. It later compared the impact of the service with the product, dropped the software and became a pricing consultancy.
For a founder whose adoption has stalled, these requests can pull in two directions. They give you something concrete to work on and a reason to stay close to customers. At the same time, the requested work may support a business that sells your help rather than access to the tool. The same conversations can keep you close to customers without settling whether the software deserves the next development cycle.
This is where "keep going" becomes too vague. If each request for pricing advice becomes another reason to polish installation, you can keep doing product work without resolving the decision customers asked you to help with. Continuing to work on their problem and continuing to build the original software are separate commitments.
The case applies to help with a customer's pricing decision. A request to install a plugin or fix an integration can be ordinary setup work. The interview leaves the service's margins and repeatability unknown, so it doesn't establish that another founder should make the same switch.
More development time spent making pricing pages easier to install needs a reason tied to installation. Requests for help choosing prices support a different commitment. RevFixr retired the product and kept working on pricing; "stop building this" did not have to mean "stop serving these customers."
Top comments (2)
“설치 전에 가격 결정을 도와달라”는 요청을 온보딩 문제로 오해하면 제품 개선만 반복할 수 있다는 구분이 인상적입니다. 이런 요청을 기록할 때 설치 장애와 의사결정 자문을 별도 항목으로 분류하면, 다음 개발 주기에서 무엇을 검증해야 할지도 더 선명해질 것 같습니다.
Yes, even when both requests come from the same customer. Otherwise, requests for advice can get mistaken for the next thing to build.
Have you had a recent request where you couldn't tell whether the customer needed a product change or help making a decision?