I try new stuff all the time and have a couple tricks to help me I want to share. Why do I try new things? Probably a personality trait coming from a low tolerance to be bored.
What do I try? From new languages, to developing small stuff that solve problems I find, to random stuff (the last one is clod plunges. I am really bad with cold and want to get better).
The thing I struggle the most is handle frustration. There is a lot of research on how important is to handle frustration and I can guarantee you there will be tons of frustration when starting doing something you do not control.
The #1 of my frustration is to be used to be fairly good at what I do. Most people are, you gravitate towards doing things you are good at. Dopamine involved. You avoid things you are not good at. So when the boredom push me towards things that are new and challenging, suddenly I have to face thatā¦ I suck at doing X. And that’s it. Its okay to suck. It is NEEDED. You have to go through that valley of ineptitude to reach a destination where you become good at it.
Second trick is to surround yourself by people smarter than you, better at whatever you are trying. Capable. Be prone to ask, be okay about getting ruthless feedback. There are times for being the smartest person in the room, but you do not learn from those. Sometimes I feel embarrassed because I’d ask a hundred questions, so that has been a challenge for me sometimes.
Beginners mentality is at your advantage. There are silverlinings into being foreigner to a field. You try things you do not know will not work and something you get amazing results. You bring a different perspective to old problems.
Success without customer meetings is veeery unlikely. I am going to be blunt here, if you are not running customer discovery calls on a weekly basis, you are doing it wrong. I know it, because I have done that mistake in the past.
Paradoxically, I have tons of experience running discovery calls and usability tests. The thing is, when it is about your product (slash side project, slash next big idea), not someone else’s, a customer discovery call triggers some subconscious fears. “The product isn’t ready”, “I’ll do it after shipping X feature…”
Last time a good friend had to push me towards running some calls. He was 100% right. The amount of usefull insights you can get from a few calls is insane. It is the difference between building something people want and wasting your time and energy. They provide…
1. Insights about what the user really want
2. Feedback on the root of issues not easily visible
3. Remove uncertainty
4. Motivation for you and your team
Users want their problem solved. If they are not being able to do it or get it, the “blame” is only on you…
In that aspect, they can also be brutal. Suspects you might have been avoiding, become blatantly obvious. (team or internal) product discussions you might have had, are suddenly very, very clear. Think in this terms…
it is better to face the problems with your ideas/products now, than build for months to discover after launching. My advice goes like this, go and get conversations with prospects from day 1. Before you start typing or designing anything…
Make a habit out of it, learn how to run them proficiently, become good at it. It will be more useful than any amount of coding or marketing you might do. It is something most people avoid, so you will acquire a unique, very valuable skill in the way.Ā #buildinpublic
I canāt stop thinking about something lately. A friend posted a story a few days ago that reminded me of a different time. When I was living in Madrid, one amazing colleague of mine dragged me to her Triathlon club. By then I had already been seriously running for a couple of years.
She thought it would be great if a couple of colleagues joined her. The thing is, it was a first-class Triathlon Club (I believe it still is one of the best in the country). Meaning most of the people were great athletes. A bit percentage of them were elite.
Some were even part of the national team. I was in okay-sh shape, but definitely not prepared to be part of that. The team’s common conversations in the dressing room were mostly about training. Strict dieting, or mocking each other not to chicken out and target to finish the next iron man in less than 9 hours. If you know Triathletes, they are characterised by their… focus.
I struggled, I was at the very bottom of the team (in a team with people 10-15 years older than me). By far the slowest swimmer, for sure. The team was already big, and there was a list of people waiting to join. If you wanted to be there, you had to be really committed.
Saying training was exhausting is an understatement. Double sessions, 3-4 days per week, plus whatever you wanted/needed to add during the weekend. Plus competing. Anyway, I ended up staying for a couple of years. Lots of lessons and findings during that time.
The thing I remember the most?
This guy in the team. The first day I met him, was in the dressing room. He said hi to some of the guys and started getting changed. I didn’t pay him a lot of attention. Just headed to the track to start warming up.
We start rolling as a group and only then I noticed he had some problem with his leg. He was weirdly dragging one of his feet. Then we shifted gears. We were supposed that day to run a few KMs at our max speed. You know what? He killed it. He was, to my surprise, faster than me.
That’s what I remember more vividly. He never gave himself any excuse, he challenged himself with every training. He was physically at a disadvantage, but man, mentally? A fucking giant. One of the most inspiring things I have ever seen. True champion courage.
I never told him how inspired I was. How much I admired his determination. I am very grateful for all the lessons of that time. The coach never treated him differently in a noticeable way. He was just one more athlete he had to push to do his best. He was showing us the way.
Showing me not to take things for granted, and not to give myself excuses. To this day, when I run, I remember him running.
Do you want your prototypes to look as accurate as possible?
One thing that comes up very soon is that you usually do not have installed the fonts that Apple use by default ?āāļø.
No worries, you can nail down your prototypes (or apps)….Apple offers the fonts they use, to download for free. You can find them hereĀ https://developer.apple…. SF (pro, mono, compact) or New York fonts. Just for you. You only need to install them and voila, available in your favourite editor.
Do you have little things that stop in your tracks and cannot “unseen” them? I do. All the time. Something that drives my (slightly OCD) soul mad is the font Obsidian uses by default. Will give you an example:
Do you see that misalignment between the line 3 and 4? Let me help you make it more obvious.
Same number of characters in both sentences, it should be aligned, shouldn’t it?
That’s the result of how that font has been designed (it is NOT a mistake by itself, just how it is built). Some letters take more space than others, causing that kind of “issue”.
If you are like me and little design details tick you off, you might understand my pain…
Thankfully, the team has enabled the change of font. You just need to go to settings > appearance. You can even define a mono font for your code!
I have two recommendations for fonts….
First, iA fontsĀ https://ia.net/topics/a…. Created by the team behind iA Writer (https://ia.net/writer). They are fantastic ļ¼ you can get them for free. They are licensed, so if you want to use them in any project, better read the licence terms. You could also use Input fonts.
The second one is Input. Input is a flexible system of fonts designed specifically for code byĀ David Jonathan Ross(http://www.djr.com/).
It offers both monospaced (what we are craving here for) and proportional fonts, all with a large range of widths, weights, and styles for richer code formatting…
Your final set up should look something like this.
Now your Obsidian looks cool AF, and it does not suffer from variable spaces in your texts!
How to take technical decisions for your side projects?
Some people allocate a sizable amount of time to this. My approach is much more simple.
First, categorise this decision. Is it a one-way door decision or a two-way door decision? Most of the time it is the latter. Being that the case, I dedicate 30-45 minutes to research what are my options. What analysis of the options already exist out there, medium, .dev, Reddit… If I think it might be relevant, ask in one of my core chat groups for an opinion. Most of the time it falls on one of two buckets, a) no opinion / educated guesses or b) extremely polarised opinions (pro or against particular options). People might reveal big hurdles or advantages for a particular choice.
By then I should be able to narrow it down to 2-3 options. Then I prioritise based on a series of factors that can be interpreted as gut feelings, but they are not. Does it look great and polished? Indicator of care and commitment behind it. Abundant documentation? lots of posts about it? great examples? good indicators of an existing community, up-to-date docs, easiness to find help when finding any blocker down the road,…
The next step is to pick the most appealing one and build a (VERY) rough version of whatever I need. Sometimes that means writing a basic script to test being able to solve a sample of the problem or a limited aspect of it. Sometimes means quickly integrating it with an existing project in a branch and seeing how it goes. The goal is to get a rough idea of how difficult will be to actually implement it at a production level, a proof of concept. As a rule of thumb, if I am not able to get a positive outcome in a short time, I discard it. The time can go from two hours to a morning, but no more than that.
The moment I hit a visible wall, I park that one and move to the next possible option. If I find a solution that is “good enough”, I just go for it, without exploring the next ones. My goal is to identify as fast as possible a viable solution for a particular problem I am looking to solve, minimising potential friction down the road. My process for not easily reversible decisions looks different (MECE, etc, but the reality is that those are indeed pretty scarce.
Avoid analysis paralysis with an approach that works for you.
To summarise this little piece of advice:
1. Simplify it and identify what type of decision you are taking
2. time-box your process
3. have a clear understanding of what success looks like before starting your analysis
Latest Becar.io product updates and deliveries for the past week! Not a lot, because I am still juggling with my consulting gigs…
Iāve made some major improvements to the onboarding pages, added support for amplitude, and now I am able to reset passwords for all users. Keep reading for more details on these updates. If you have any feedback on the new onboarding pages and changes, please let me know!
Improved Onboarding Pages
Iāve made some major improvements to the onboarding pages! These changes should make it easier and faster for new users to get started with our product.
So far, 5X conversion rate ??…
A clear sign of how poorly designed was the flow before. To be honest, it is still a disaster. I rather have some friction there . It ensures clear interest from early adopters. The ones signing up
have a real interest in improving their handling of their professional time…
I was considering a couple of options and there is still a few better options than the one I ended up deploying. But there were a couple of technical implications that would have increased the time to deliver.
This version is versatile and fast enough.
I am still testing better ways to deliver value with becar.io and do not want to focus too much on the external layers (yet). This sprint will be focused on the core of the product, increase value delivery and having more interviews with customers and prospects.
Added Amplitude
Iāve added amplitude so that I can now track your progress and performance issues over time.Ā @Amplitude_HQĀ is a great tool to measure your product. Instrumentalising products has been my bread and butter for years, but had somehow delayed it…
It has been barely 2 months since I started building becar.io. At this stage having qualitative feedback, direct from users is way more important. In any case, if you havenāt already, be sure to sign up for a free trial…
Reset password
I was able to reset the passwords manually, but users were not receiving any notification. I had yet to connect @Firebase to be able to sent the emails with the reset link. This was way easier than expected…
Just to clarify, I sually I would not care about adding anything like that (In fact I still have to do it manually), but I had two requests this week to reset the password and one was from my brother. Hard to ignore…
Thanks for your patience as I make adjustments and evolveĀ it! I need to allocate time to have something decent (What can I say, the shoemaker’s son always goes barefoot…) .
It’s been a bit more than two months since I decided to create something around a problem I care about. I deeply hate meetings. Inefficient meetings are a plague. I am building a solution to help you improve your meetings. What final shape that will have, I am still not sure, it will definitely change along the way, but it is something I want to tackleā¦.Ā #buildinpublic
Speed is key. I know, it is not as fast as developing and testing in a week as @shl process (I have a couple of ideas I’ll test his process with, but not this one). I had a few domains saved for side projects and that’s the one better fitted for the projectā¦
My goals these past months have been a) validate if there if it is a problem want to have solved (can it get traction?) b) if I can deliver the technical parts, c) can I deliver value by solving the most annoying parts of meetingsā¦
So far it is going great, but I am gonna review some of the mistakes I have made this time. I think it is also important to review your errors. They are not the only ones, but the more painful ones.
Diving fast into developing something you do not knowā¦
Launching the Chrome Calendar Extension. I had zero experience with extensions. I have learned a lot about it during this time. Something that is kinda tricky when developing extensions is there is no easy way to declare environment variables.
Why is that important?
The first time I submitted the extension to the Chrome Store, I forgot to change the (hardcoded) API endpoints! It was approved, but was making the calls toā¦ localhost ?āāļø. Another important learning there.
Every submission to the Chrome Store goes through a cycle of up to 10 days to be re-approved. Sometimes it takes less time, sometimes more. Insight from all this?
Run an exhaustive checklist, making sure that all that could be broken is not brokenā¦
Regressive tests are your friends. Not at this stage though, many things will change. But eventually will have a set of regressive tests to run before submitting. Testing chrome extension is a different beast. Will probably write about it at some pointā¦
Mistake number 2, not checking my requirements when picking my stack
Without going into much detail, I found out, when I was already committed with a stack (having developed a substantial part of what I had planned), that some of the things I wanted to be able to do, wereā¦
complicated. NextJs comes with a couple of great advantages, like having an API out of the box. Well, that was not easily deployed on my platform of choice. Also generating dynamic pages had some complexities.
In the end, I was able to overcome those hurdles, but I had at least a couple of stressful days.
Insight?
Listing the critical needs of your project. Going through them, and checking they are available in your stackā¦ can save you a lot of headaches.
I think the main lesson is it is okay to make mistakes. Shipping fast, finding insights sooner, make up for the mistakes.
? 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Ā prepare,Ā contributeĀ andĀ provide feedback. All without leaving your favourite Calendar.
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.
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.
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.
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:
Insecurity, fears
Viability
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.
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.
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.
