Gleebeam

Based on feedback we’ve gotten from some early users, we’ve begun the year by releasing a fairly major update.

• All notification template fields are positioned on a fixed grid to solve two main issues. First, now users have fewer decisions to make about how their templates should look, and, second, all fields now have fixed dimensions, which fixes problems with long text overflowing notification borders.
• In cases where the text doesn’t fit within the dimensions of the field, we’ve implemented text autoscroll, which scrolls overflowing text automatically in the dashboard view.
• All fields can have optional titles, which helps with labeling fields to let the team know what information they contain.
• Notification sizing has been improved within the dashboard cards.
• The sound selection menu has been redesigned in the editor.
• There’s now a default template design that greets all users when they create a new template and provides information of what they can do next.
• Optimizations for some built-in TV web browsers have been implemented. Unfortunately, this has made the dashboard less responsive on more common and fully-featured browsers – this will have to be addressed in a future update.
• Notifications will now be labelled as “NEW” on the dashboard for an hour after they have been received.
• Fixed a bug where emojis were not parsed in the dashboard.
• Several other minor UI fixes

https://blog.gleebeam.com/2020/01/07/gleebeam-january-2020-updates/

Summary

I decided to switch focus from marketing to product development this month as some feedback from early users revealed major usability issues in the prototype. Another reason for the switch was that I was feeling exhausted from messaging people and writing articles - solving some more technical challenges seems to have been just what I needed to recharge my batteries.

The plan for January is to gather more feedback from potential users to be able to decide with some confidence on how to move forward with the project. Either I'm able to find a marketable position for the product, or I have to start working on something else. I'll have to figure this out in February.

Comfort Zones

It seemed that in late November and early December I had successfully moved out of the (really cosy) comfort zone of mostly developing the product and pushed myself more out in the public, where the challenge was finding people to talk to me about the product. At some point, however, it became apparent that I had found a new comfort zone for myself in (who would've thought) content marketing!

I wrote several tutorials for Gleebeam and started posting regularly on Twitter, LinkedIn and IndieHackers. This was pretty great for three things:

1. Testing and documenting product use-cases,
2. Building an audience, slowly but steadily,
3. Driving hundreds of people to check out Gleebeam.

What this wasn't good for, however, was sign-ups and feedback from users who might actually need the product. The solution is, I believe, nothing other than to leave my new comfort zone and push myself further towards doing the uncomfortable - sending emails or direct messages to specific people that I think could be interested in trying Gleebeam to increase my understanding of their needs from dashboard software.

Niches

The idea behind Gleebeam appealed to me to a large extent because it seemed like Gleebeam would be a product for a small niche. The niche would be so small that few or none of the big players would already have, or would be inclined to make, similar products. I'd have a small number of customers but enough to break even, and then, if necessary, look for ways to expand further. Some initial competitor and SEO research seemed to validate this idea, though it also made me worry whether anyone is actually in any explicit way looking for the solution Gleebeam now provides.

I still believe there are customers out there for Gleebeam. The only thing I'm worried about is whether the niche is not too small - so small that it's extremely difficult to find these customers. I've been thinking about this increasingly more in December. I have to conduct significantly more user interviews to gauge how potential users feel about Gleebeam and see where future opportunities for the app might be. I currently believe that these people could be sales, HR, or communications managers in companies of 5-50 employees.

Next Steps

Now that the usability problems I found will be fixed, I'll try to gather more feedback from Gleebeam's current users and expand my efforts to reach more people in a more targeted way. Sometime during February, I will have to decide whether to pivot towards a more full-featured data dashboard solution or to start working on other ideas.

I'll attempt to send 100 emails or other direct messages to a targeted audience in January. Of these, I hope that 10 will result in conversations about Gleebeam or the general dashboard needs of these people.

In November I’ve implemented the following improvements and features.

🖥 Connecting to external dashboard screens without having to sign in with Google. It works by opening a specific URL on your screen and entering the displayed passcode in your Gleebeam account.

⚡️An official Zapier integration, making automation of notification much, much simpler.

🎓An onboarding tooltip for new users, implemented in the step where users were most likely to get stuck.

🦶Improved website footer layout. The previous one was way too rough!

🖼A better-looking illustration in the first fold of the website to make it clearer what Gleebeam is and how it is supposed to be used.

Thanks a lot to all of you who tested Gleebeam in November and provided feedback! 🙏 It was super helpful.

I started writing a blog immediately after launching Gleebeam in October. Now looking back at it, it looks like I've written around 1 post per week. Not a lot but probably not bad either, considering all the other marketing I've had to do to get any traffic to Gleebeam's site!

My aim with the blog has been to publish guides for different Gleebeam use-cases to see over time, which of the use-cases gather most attention. I don't have a target audience nailed for Gleebeam yet and the blog should provide one of the data points necessary for nailing it!

To celebrate, I've also finally created a Gleebeam Twitter account!

🎉 https://twitter.com/gleebeam

I've wanted Gleebeam to have a Zapier integration ever since I came up with the idea around 6 months ago. I'm happy to announce I've finally built it!

The integration significantly improves the ease of connecting different apps to Gleebeam. It took around two days to build including the research I had to do to understand how to make it authenticate with and securely get user data from Firebase. The Zapier platform also had some bugs which slowed things down for me - since then they've reported to me that the bugs have been fixed though!

There are two ways to build a Zapier integration:

1. Using the Zapier CLI. This sets up a Node project for you and allows you to push updates to the Zapier platform. You get more control over your code, better version control and the ability to include third-party packages.
2. Using their visual builder. Here all set-up happens in their web integration builder. You define your authentication endpoints, triggers and actions right in the browser. For most of these things, you can also switch to editing code snippets that make and parse the HTTP requests the integration will have to make to your API.

I started with the CLI, but, because of a nasty bug that prevented me from pushing any code to the platform, I switched to the visual builder. In general, it works fine but it was not always clear to me by reading their docs how it all holds together - i.e. how the integration's state is saved and how can different input fields dynamically interact with one another. So I went through a pretty brutal trial & error process but, in the end, it seems to have turned out well!

Are you using Firebase and want to build a Zapier integration? I have a tip for you. Implement all authentication and data fetching using Firebase's REST API. This was not obvious to me at first as I had been used to only using the Firebase SDK to make all my auth and database requests. Knowing this initially could've saved me a few hours.

Are you a Zapier user eager to test out new automation possibilities? Use the link below to try out the Gleebeam integration! You'll need a Gleebeam account with a created notification template.

To check out Gleebeam, visit https://gleebeam.com
To check out the Zapier integration, visit https://zapier.com/developer/public-invite/73037/128ec7cdebf34117e0f135b701383a15/

I've received so much valuable feedback on Gleebeam lately - feedback from the Indie Hackers community is a significant part of it. This has helped me to validate that some things that bothered me about the app also bothered the users!

So I'm happy to announce that Gleebeam now has:

1. Onboarding. Previously it didn't have any and some users reported getting lost after creating their first notification template. So I implemented the minimum viable onboarding (MVO) to fix this - a single tooltip that now will tell users what to do next!

2. A feature for displaying the Gleebeam dashboard on an external screen without having to log in. I got feedback where a user could only open a specific URL on a screen but for technical reasons couldn't go through Google Authentication to view their dashboards. So I implemented a feature where a screen can be connected to a Gleebeam account via a code that appears on the screen when you visit a specific Gleebeam URL.
   This is a feature that I had seen in Geckoboard and wanted it to be implemented in Gleebeam as well because having to authenticate on every screen you want to put Gleebeam on seemed pretty awkward. It took much less time than expected - just about a day!

My goal is still to get as much feedback as possible from people who have needs that could be satisfied by Gleebeam. This should help me understand where to go with the product next!

Decided to try Google Ads for the first time ever last week. I aimed to see how the system works and whether ads would be a viable driver for Gleebeam sign-ups.

I set up three ad groups based on three separate target audiences I wanted to target. These were

1. General CRM automation searches
2. Specific sales deal celebration searches
3. Employee achievement recognition & celebration searches
   Each of these groups had two ad versions where I varied the copy to see what wording would convert better.

I set my daily spend limit to $10, but I didn't set a click cost limit because I had no frame of reference for how much a click costs. Altogether, I got 55 clicks from 2.5k impressions - some ad groups & keywords did better than others. In total, I spent $85.

I got exactly 0 sign-ups from ads from this.

I learned that

1. Google Ads are expensive! I was surprised that some of the initial clicks cost around $2 per click. I have no other experience with CPC advertising though so this might as well be expensive only to me!
2. Google Ads are fun! There's a lot to monitor and optimize in ads and a lot to experiment with. Some ad descriptions convert better than others (for me, it was the phrase 'create delightful moments in the office' that seemed to draw in more traffic based on the sample I got).
3. Google Ads might not be the best channel for me now. I'll probably leave it on for the most targeted ad group and set a click cost limit to make the costs more controlled. I'll also try to do some minor optimizations for the ad content and then focus on other channels for now - so far all of Gleebeam's sign-ups have come from either organic searches or me reaching out to people directly.

Regarding the title of this post, yeah, right at the end of this experiment I paid $20 for a single click! And what is more, the search term the click came from was 100% irrelevant (it was "celebration garage sale 2019").

The MVP for Gleebeam is done and deployed at https://gleebeam.com. It includes:

• A fairly simple marketing site - I use Vue.js as a front-end framework for both the website and the app
• Sign up with Google only
• Three web application views (and several pop-ups for additional information/actions), one of which (the notification template editor) took a LOT of effort to make
• Stripe for payments
• Mailchimp for communication
• Google and Firebase Analytics for gathering all the data
• Hosting, database and serverless backend on Firebase
• Appzi for gathering user feedback
• A public Notion page for the documentation
• Giphy integration for easy GIF access in the notification editor
• All the HTML meta tag stuff for sharing and SEO

I feel it's just as important to mention the things I left out of the MVP:

• Any way for users to manage their accounts
• Multiple users per account
• Other auth methods besides Google
• Privacy Policy and Terms of Service
• Blog (I've implemented a blog with Wordpress now since the MVP launch)
• App onboarding - not expecting a lot of users initially so I'm happy to help them each individually and treat it as a customer research opportunity
• Proper documentation page - just using Notion for now
• Lots of different feature ideas for making the app more polished and feature-complete (e.g. easy TV dashboard set-up as in Geckoboard or confetti-like effects when the notifications appear on the dashboard)
• A Zapier app for Gleebeam since it is easy enough to use the Zapier webhooks app
• Lots of minor improvements!

Some learnings:

1. Integrate payments only if you have a sizeable audience of people eager to start using your product immediately after launch.
   It will likely be a waste of time initially as you probably want to first validate your app's prototype and learn about the few users who will want to use it initially without having them pay to make full use of the product.
   This was my first time integrating Stripe in an app so I wanted to do it to learn the API. It took quite a bit of time to handle all free/paid tier upgrade/downgrade scenarios.

2. Don't build too much specific functionality before you know what users expect from the product.
   The part of Gleebeam that was most difficult to build was the notification editor. Now having spent more time thinking about it, I'm pretty sure the app doesn't need an editor with so much flexibility - it only adds to the set-up overhead users experience when they start to use the app.

3. Lots of technical stuff.
   I am a self-taught developer and am constantly learning incredible amounts of things. Some noteworthy examples for what I learned with this project: Firebase Cloud Functions, Firestore Database (I had previously used their Real-time Database solution), Firebase Hosting, tests with Jest, multi-page apps with Vue CLI, Stripe API, and the list could go on.
   Learning this is not essential for making Gleebeam a sustainable business but I just really enjoy expanding my tech skills with my projects and would never willingly stop doing this just to save time. That said, I don't think I reinvent the wheel too often - the goal is just to push my current limits and not to learn how EVERYTHING works.

Why I decided to work on Gleebeam

At the company where I work TV dashboard notifications have been used to celebrate important events and to keep the team informed. For instance, when we launched a new product, we wanted to play a sound in the office every time a purchase of the product was made.

These notifications weren't easy to set up and the set-up was also fairly insecure - we used a Chrome extension that played a sound whenever a Shopify order confirmation email was received in Gmail. Later on we wanted to play different sounds for different products but that was too painful to set up. Long story short, I got inspired by this use-case and am now exploring it with Gleebeam!

What my plan for the product is

I'd first like to target the product at companies that are already familiar with tools like Zapier and feel comfortable with setting up some simple webhooks there.

I'd like the TV dashboard notifications to have both visual and sonic elements. Sounds can get really annoying so users would have to have an option to just, for example, display a GIF when something important happens.

In the future Gleebeam could support setting of milestones for notifications to gamify the experience a bit more. E.g. users could set up a milestone "I want to aim for receiving this notification 10 times per day" and then these daily combos could be displayed on the Gleebeam dashboard.

Why I like the idea

1. I can develop it mostly on my own with the help of my girlfriend who's a UI designer.
2. I can learn a lot. I have never done any significant back-end programming, and I have also never implemented a payment processor like Stripe. Really looking forward to this!
3. I love automation tools like Zapier as well as extending the functionality of different apps using code.
4. I think Gleebeam takes a slightly different approach to analytics dashboard apps. I'd like to see if it can be developed into something useful.

What my concerns are

1. I don't really know if there is a market out there for this. Judging from what I've managed to discover in various SEO keyword seach tools, it might be really difficult to find sources or organic traffic for this.
2. I'm going against the popular advice to validate the product idea with market reasearch before beginning to build it. I am having conversations with some friends and colleagues about it but am not actively searching for potential customers to discuss Gleebeam with. I see Gleebeam as a great opportunity to improve my technical skills, which kind of justifies this approach (as long as I don't spend years developing it only to discover nobody needs it).