Make your Calendar experience 10X better

? Announcement, I am launching Becar.io, Calendar Extension  (meaning “intern” in Spanish). A better experience for people that have lots of meetings and are looking for ways to make their meetings harder to ignore, more impactful and effective. It allows users to add an interactive agenda for every meeting. Asking attendees to preparecontribute and provide feedback. All without leaving your favourite Calendar.

Becar.io, supercharge your Google Calendar, make your meetings experience 10x better
Supercharge your Google Calendar meetings without leaving the calendar

Why am I launching it? 

I decided two months ago to make a personal commitment to develop solutions to a couple of problems that seem interesting. The first one? meetings. I do hate having unproductive meetings. My theory is that I am not the only one.

How bad is that as a problem?

The Harvard Business review returns a staggering number of 16K documents related to meetings. From why meetings go wrong, to how to design an agenda or how to run a meeting. I am fairly sure the problem is there.

Think about the last time you attend a poorly organized meeting. Have you ever had people attending meetings with no idea of what’s going on or any homework done? Tons of meetings that should never have taken place to start with. Thousands of wasted man-hours

The overall experience of having meetings is pretty much sub-optimal. There is a general assumption that some negative aspects are impossible to change, a form of learned helplessness. My bet is there are a few powerful opportunities in that problem space. At different stages, pre, during and post-meeting. Becar.io is the first iteration of a solution to the problem.

What it does do for you?

It reduces friction when organizing a meeting by making it easier structuring them with templates. You can ask attendees to do stuff and hold them accountable. Every meeting has a page where all attendees can see what is expected from them and who has done their homework before the meeting. All without leaving your Calendar, using a browser extension.

Make sure all your meetings are PERFECT.
Enforce best practices and accountability.
Having unstructured, wild meetings is a choice

To be honest, it is still rough around the edges and only the key features work. But hey, launch fast, get feedback quickly and iterate your way until it is something people love.

Check it out, sign up or ping me to get access and I’ll send an invite. If you have meetings back to back on a daily basis and you are up for a quick chat about your problems I’s be SUPER grateful if you let me know.

Calendar stats, find out how much of your precious time goes to meetings and show how much all those meetings cost
Get insights on your time allocation and associated costs

P.s: something I decided to add last minute. You get stats on how you distribute your time, how much time you spend on meetings, and how much that costs. You can track if your time spent in meetings goes down over time with better-organized meetings.

A better approach to launching products

A better approach to launching

Lately I have been considering if there is a better approach to launching products. My time is limited because of my freelance consulting, other projects, etc. I have committed to launch new experiments during the next months though. I have many ideas I want to test. Problems I want to address. Potential solutions that could help people tackle those problems. Being my time & energy limited, optimising what and how launch those is paramount. But more importantly, launching means moving things forward. Not so easy.

A kindly reminder on the importance of launching was this article, Why Developers Are Building So Many Side Projects. From Future, the a16z newsletter. I had another one yesterday, with my friend launching Magic Board AutoPaste Keyboard. He has a toddler. Has organized two weddings in different countries in the last month and went on his honeymoon… and still delivering like that!

Launching a product is always scary. There are ways to understand why it is scary and why it should be a priority. Rationalise the need of fast shipping. Minimise risks and take advantage of ways of launching faster. I have never regretted launching too soon, but I have had the feeling of launching too late.

The blockers to launch fast would be, in this particular order:

  1. Insecurity, fears
  2. Viability
  3. Launch execution

Fears

The problem with launching is 90% of the times, self confidence. I have a very few examples of product launches where the quality of the product was the issue. On the other hand, I have tons of examples were a fast launch would have solved myriads of problems and wasted resources.

My way to approach it now is a) think in terms of potential outcomes and b) minimise risks.

Mapping potential outcomes. What are they potential outcomes of a launch? Lack of interest is number one. The one thing you really want to know as soon as possible. Face that is the case and deal with that possible outcome mentally. Finding out soon is not a bad outcome, finding out down the road is. Customers dealing with a buggy solution? if they have interest, they will stick around. Take a look at how many terrible products people use for years.

Minimising risks is even easier. Does your product put lives or business at risk? If so, you should not be using a quick launch methodology, sorry to break the news to you. Otherwise, what would be a catastrophic result of things going wrong with your product? Plan for that outcome

Just launch. Put your product in people’s hands and listen. That’s your lifeline.

Viability

I probably spend too much time validating something can be done. I am a perfectionist, so I like to be 100% sure something is possible before launching. The problem with that approach is that sometimes you discover there are more important variables that should have been resolved before tackling the technical aspects. From having an unaffordable CAC to being a type of market I am not really interested in being part of. Launching would have helped solve those questions beforehand.

Building it is just the first step. The faster you reach it, the better.

My new approach to this the last months has been to have a side track to experiment with technical validation of ideas. Think in terms of “For me to solve problem X, I should be able to use Y technology in Z way”. Go and test that is possible in a barebones, pure technical environment. Tinkering with the technology. If I am not able to validate the technical side of a side project by playing with it a few days, it is probably not something I should be attacking.

Execution

A key aspect. Tightly tied with the fears point. In the past I have worked with teams where this was the main issue. “We want to launch, but when the product is ready. If the product is not really there, how would we know people really want it?”. That is a catch 22. Another friend sent me this meme not too long ago, to remind us about it.

The startup need users loop

There is a lot I could write about this mentality or issue. How that is a red flag that signals a poor product direction or a display of lack of experience launching products. It all can be summarised: launching fast and imperfect triumphs a too-slow-too-late perfect launch.

There are exceptions of course, but be sure that the odds of you being in the former are massively higher than you being an exception.

I am not pleading for bad execution. Neither a proponent of throwing best practices through the window (this article, A development process startup founders should use to ship features weirdly fast is a good example, although it makes a couple good points). I am a firm believer of execution being exponential. I believe in making smart choices as a competitive advantage. Embracing constrains and trimming unnecessary weight is the best possible way to fast execution.

Ship like there is no tomorrow. Focus on what is important, the rest will take care by itself.

Previously oorei dot com | Comments are disabled