Hello y'all!
It's been a while since illness and vacation time on our side. Luckily, we could still create this pretty long update right before christmas. Previously, we shared a lot about the feedback we've received. We continue to collect more information and as we were getting very positive reviews for the general idea, we started to think more about potential users. So with this update, we want to share more about potential users and who we think could benefit from our tool the most.
Actual frustrations led to a technical solution
When we started thinking about a product that we could handle, we saw the issue with forms - especially when having to send information to the government. Think of complex language and jargon, lengthy and time-consuming, fast session timeouts and lack of technical accessibility in many cases. Being able to quickly switch tabs, research what you need to put in, make screenshots to document what you put into a page and have most of the information available in your files, makes it a lot easier to fill them out on a computer instead of a phone. Now when you end up on a page having to send a document that you haven't scanned yet, it may be easier to scan it with your phone and send it quickly to the device.
After talking to quite a few people now, most of them know and share these frustrations - but this is just one out of many for government forms: Since the whole process tends to be frustrating anyways, it didn't seem to matter that much for this specific use-case anymore.
A solution for no problems?
In the startup ecosystem, you're likely to hear the advice “do not build a solution and then search for a problem”. It's better to have a defined target group, a specific problem and then solve their issues. As a developer, it's easy to fall into the trap of building software that you think is great, but doesn't provide much value to a user.
It may seem that we have fallen into that trap, considering that we've built a working prototype. On the other hand, we're still iterating a lot on our prototype. We do not spend too much time on it right now, even though we know we could improve a lot. We also know that we could focus in various directions: On-premise solutions with integration into frameworks, providing an external docker service, a cloud-based solution with different pricing models, making the various steps available through JavaScript to build completely custom elements or even develop a browser extension to allow it to work on any form.
We did get quite a few ideas where our tool might turn out as useful. There are lots of scenarios that can be significantly faster to do on a computer with a fast way to add images from the phone: Think about customer support for complaints and returns. Social media management for businesses, creating educational content, adding sketches for custom product orders, online contests or promotions, sharing cooking tips and recipes, … Many platforms that specialize in these niches are still tailored towards an audience sitting in front of a computer.
So we are going to pick the most promising of these scenarios and see how much interest we can gain. What technologies do we need to focus on? This should be directly influenced by what the market needs.
Who are the decision-makers and budget managers?
The big question is for whom are we building this and who will ultimately decide whether to use our solution. We know this may change in the future but as we've mentioned earlier, we don't want to spend too much time overthinking anything. We made the call to try out e-commerce with complaints and returns first. This could be a huge market and even if we find out they don't see enough value in the solution, we can still learn from their experience with various software tools.
One particular story we heard about complaints and returns was about customers who send in model numbers by hand. Instead, the customer service would like to get a photo sent in of the plate on the hardware. This contains their model number and some other useful debug information. Since most of their customers use a computer to fill out the form, they don't have the image available and just type the information - likely with typos and without the other useful debug information on the plate. If they had a way to say “take a photo of the plate through this QR code” in their forms, this would greatly increase the amount of images they would receive, improving both the work of their support staff and the experience of the customer. They do not need to manually transfer information from a photo anymore and can easily upload the picture itself.
Based on such scenarios, the buying decision for a tool like ours is likely being done by people responsible for the support team. What would a Head of Customer Experience like to hear, know and read, if we are to prepare a presentation for them? What kind of texts would be necessary to convince someone to try our tool?
We're likely to work on this soon. One more thing we should always keep in mind is developer experience.
Why is developer experience beneficial?
A few years back, when Jörn was in Toronto, he met a sales person from a big tech company. The person told him that the licenses for schools and universities are basically free, because they want the students to get into a job and be trained on their tools. So when a company needs to hire new people, they will push towards the tools they already knew and used, creating pressure to buy actual licenses. Essentially, they create advocates for their products early on.
How does this anecdote relate to development tools? If we achieve a really good development experience, this could lead to something similar: Developers do talk to each other about how they achieve things at networking events, conferences, workshops, etc. They also tend to switch jobs from time to time and keep working with tools that did work in the past or push the company towards them, if they can.
In general, the developers are usually asked for advice by the decision-makers. They need to estimate how much effort it takes to make it available in their software, so the decider can tell whether it's worth and valuable enough. If such a feature can be implemented in a fast and simple way - thanks to a good developer experience - we create advocates for our product and have an easier sell.
Getting decision-makers to test
Our next goal is getting people to test our product / tool who are authorized to buy. To achieve this, we are going to do the following and track which will work best:
- Find direct or indirect contacts in our networks that work as head of customer experience, support or service through LinkedIn and similar channels.
- Make the tool as easy to test as possible - that means providing an online demo.
- Create landing pages to find people searching for a solution to improve their complaints and returns.
We know there are lots of developers and founders in almost every type of industry in our contact lists. For sure there are some working in e-commerce or know people actively searching for such a solution.
Let's find them! If you know someone who works in this area and could need something like this: Please give us a hint or make them aware that our solution exists.
Follow us on LinkedIn , Twitter / X, and and star our build-in-public repository for updates and the Flottform repository for implementation details.
See you next year!
