The Feedback Form That Became Signaldeck

Signaldeck did not start as a separate product.

It started as one question inside Timetoast, the timeline maker I previously built.

Enough people were using Timetoast that guesswork was no longer good enough. I needed a better way to understand what users valued, where they got stuck, and why some of them decided to leave.

At first, that sounded simple enough. I did what a lot of founders do when the problem looks small: I built the first version myself.

It was just a form.

When someone closed or canceled their account, I asked one question: why?

That small question became one of the most valuable additions I had made to the product. It gave me the first steady stream of direct feedback from people who had used Timetoast enough to make a decision about it. Some were paying subscribers. Some had been around for a while. Some were leaving because I had not delivered what they needed.

That feedback helped me see what customers valued, where the product was falling short, and which problems were worth paying attention to.

The form worked. Then the feedback problem got bigger.

The first useful signal came from churn

Churn feedback is uncomfortable because it arrives after a decision has already been made. But it is also direct.

When someone cancels, they usually have a reason. Sometimes the reason is not something you can fix. Sometimes the product was the wrong fit, the project ended, or the user only needed the tool once. But sometimes the reason points at a product gap, a confusing experience, a missing feature, or a pricing objection that has been sitting there quietly for months.

The first version of my feedback system only had one job: capture that reason before it disappeared.

That was enough to make the product better. I could read the answers, spot repeated problems, and compare what paying users cared about with what I had assumed they cared about.

The lesson was simple: you do not need a complex research program to learn something useful. You need to ask a question at a moment when the user has context and a reason to answer.

Then feedback started arriving in different languages

Timetoast was used around the world, so the answers did not all arrive in English.

Some of that was fine. I am fluent in Dutch after living in the Netherlands for more than 12 years, so Dutch feedback was easy enough to read when it appeared. The harder part was everything else.

For those responses, I manually copied text into Google Translate, read the translation, and tried to keep enough context in my head to decide whether the feedback mattered.

It worked in the way many founder workflows start. It was manual, a little messy, and good enough when the volume was low.

It was not scalable.

Translation was only one part of the problem. I also wanted to be reminded about feedback later. I would read something useful, make a mental note, then rediscover the same theme the next time I sat down to review responses. That meant more copy and paste, more rereading, and more reliance on memory than I wanted.

Once I had 50 or so answers, the problem surface started to change. The question was no longer, "Can I collect feedback?" The question was, "Can I keep up with it well enough for it to change what I do next?"

I needed feedback from users who were not leaving

That is the shortcoming of churn feedback: it explains a decision after the user has already made it. It can tell you why someone left, but it does not tell you much about people who are still getting value, still hesitating, or quietly working around friction.

I wanted to hear from those users too. Some were happy on the free plan. Some were getting value, but did not see enough extra value in the paid plans to upgrade. Some probably had small frustrations that would never make them cancel because they were not paying in the first place.

Those users were important, but they were almost never asked anything.

So I added a general feedback button. It gave people a way to send thoughts without waiting until they were angry, stuck, or ready to leave.

That was useful too. It gave me a broader view of the product. Churn feedback showed me where the product had failed to keep someone. General feedback showed me what users wanted while they were still engaged.

But the volume started creeping up again.

I was still dealing with translations. I was still reviewing everything manually. I was still trying to connect scattered answers to product decisions. And alongside all this, I occasionally used external survey tools when I needed a more structured answer. Those were useful, but they were intermittent, detached from the product experience, and the cheaper tools I had relied on were becoming less generous over time.

The system was growing because the need was real.

Context made the answers better

The next step was in-app, contextual feedback.

Instead of asking a broad question somewhere generic, I could ask a question in the part of the product where the answer made sense. I could ask about a specific screen, flow, feature, or product moment. I could also segment who saw the question, such as free users versus paid users.

That changed the quality of the answers.

Contextual feedback is often better because the user is still close to the thing you are asking about. They do not have to reconstruct the experience from memory. They can tell you what is confusing, missing, or surprisingly useful while the product moment is still fresh.

For a founder, that is powerful. You can ask:

• What nearly stopped you from finishing this?
• What worked better than you expected?
• What is missing before this feels useful?
• What made this worth using again?

The answers are easier to act on because they are tied to a moment in the product.

But this is also where the problem became clearer. I was no longer adding a simple form. I was building a feedback product inside my product.

Feedback collection became a second product

By this point, I had database tables for feedback, different question types, different answer types, segmentation rules, review screens, and dashboards.

I had churn feedback, general feedback, and contextual in-app questions inside Timetoast, plus survey responses from external tools. I had free users, paid users, users in different countries, users answering in different languages, and product decisions that depended on understanding the patterns.

Then I wanted to process the feedback properly.

I wanted translation. I wanted summarization. I wanted theme identification. I wanted sentiment insights. I wanted to know what was repeating, what was urgent, what was noise, and what should be followed up on.

That was the point where the shape of the problem became obvious.

Feedback collection was not a small feature anymore. It had become its own workflow, with its own data model, its own review experience, and its own operational habits.

And that was a problem.

Timetoast needed my attention as a product. The feedback system was useful, but it was also pulling product, engineering, and mental energy away from the thing users had actually signed up for.

I did not want to keep building two products side by side inside one codebase.

Support and feedback are related, but they are not the same job

I still use Intercom, the customer service platform from Fin. It is useful for support: it reduces the load of answering common customer questions and helps users get unstuck.

But support and product feedback are different jobs.

Support is often about helping one user complete the thing they are trying to do right now. Product feedback is about learning what many users are experiencing so you can decide what to improve, remove, explain, or build next.

They overlap, but they should not be forced into the same workflow.

For me, that distinction mattered because I had to be careful with my own time. I could not run always-on support for every free user at every hour of the day. At the same time, I did want to hear from free users, because free users often show you where onboarding is unclear, where pricing is uncertain, and where the product creates value before money changes hands.

Feedback needed to be easier to collect without becoming a support burden.

That was another reason Signaldeck needed to exist outside the product it was helping.

My advice: start with one form

If you are at an early-stage startup, I would still start small.

I would not begin with a giant survey, a heavy research process, or a complicated taxonomy. I would start with a simple form and one question that connects to a decision I already need to make. If you only add one feedback form, make it a churn form. When someone cancels, ask why before that context disappears.

Keep it simple enough that you will actually read the answers.

If that starts to help, add one more question around the next product decision:

• If users are leaving, ask why at cancellation.
• If visitors are bouncing from the pricing page, ask what is unclear or missing.
• If free users are active but not upgrading, ask what would make the product worth paying for.
• If a feature is underused, ask what users expected it to help them do.

Then watch for the second-order problems.

Are answers arriving in languages you cannot easily read? Are you copying responses between tools? Are useful comments disappearing into memory until the next time you review them? Are you trying to ask different questions by plan, page, or product moment?

That is the point where the form has become a workflow.

If you run into those problems, consider checking Signaldeck out to see whether it can help. It is built for that transition: when feedback has proved useful, but collecting, reviewing, summarizing, and acting on it is starting to become its own job.

I would make sure each answer kept its context: where it was asked, who saw it, what plan they were on, what language they answered in, and what decision the question was meant to inform.

Then I would set up a lightweight review loop:

1. Ask one focused question.
2. Let responses collect for a short period.
3. Translate and summarize the answers if needed.
4. Look for repeated themes.
5. Decide whether the feedback changes what to build, fix, explain, or ignore.
6. Follow up or ask a better question.

That loop matters more than the form itself.

Why Signaldeck exists

Signaldeck exists because feedback is easy to collect once and hard to keep useful over time.

The first version of my own feedback system was just a churn question. It helped immediately. Then it grew into multilingual responses, general feedback, contextual forms, segmentation, dashboards, summaries, themes, and reminders, with external surveys sitting awkwardly alongside the rest.

Each step made sense on its own. Together, they became a product.

Signaldeck is the product I wish I had been able to plug into Timetoast when the first simple form started proving its value. It is for founders and small teams who want a lightweight way to ask useful questions, review the answers, and keep feedback close to product decisions without turning their own app into a feedback platform.

For the current product and capabilities, start with the Signaldeck homepage. To read more about the public launch, see the general availability announcement.

Signaldeck is still a young product, and I am improving it quickly. The direction is the same one described in this post: make it easier to ask useful questions, understand the answers, and turn feedback into better product decisions.

The goal is still the same as that first cancellation question: ask something useful, understand the answer, and let the feedback improve the next product decision.

If you are at the stage where feedback is starting to appear in too many places, start with one clean loop. Pick one product moment, ask one question, and decide what you will do when the answers start arriving.