• When you are building a B2B SaaS product it’s very hard to know what the appropriate price for your product is. Even if you magically found the correct one, it might not be the correct one next month when you made the product better and you are providing new values. That’s why you need to be constant experimenting with prices on your app.

    When I started my career I was afraid of raising prices, of having to justify why they went up (I wasn’t even aware of grandfathering). When I started to learn that most entrepreneurs set their prices too low, my partner and I decided to set the price too high and then lower it if it was necessary. Without realizing we painted ourselves to a corner.

    We didn’t want to just lower prices, we wanted to experiment with prices (switching from per-user to 3 plans, things like that). The problem was that anything we would come would cost a different amount for each customer. For some customers it would go up, and that wasn’t a problem, because we would grandfather them in. But for some customers it would plummet.

    There were two options for those customers:

    • Lower their prices according to the new plans and lose the revenue.
    • Don’t lower their prices and risk them being very angry about overpaying.

    Because we were a bootstrapped startup living month to month, every time we discussed this we would get stuck in a cycle of what-ifs one or the other situation. Eventually one day we made a rule of forbidding talking about pricing (trying to get some work done, because we would spend days and days discussing pricing).

    Eventually I found myself wishing that instead of starting with a high price and lowering it for experimentation, that we started with a low price and raising it for experimentation. We would have experimented much more. There’s another obvious solution which is not depend on the sweet revenue of those high prices. But even though it’s simple, I don’t think it’s easy… like sitting in front a pizza and not having a slide. Yeah… right!

    Next time I want to increment prices over time and even then try to give myself room for experimentation.




  • Dashman

    Why I think Dashman failed

    by

    Dashman

    Almost every time I tell someone what Dashman, one of my startups, was, their response is: “Oh, I really needed that back in 20somethingteen”. Yet I didn’t manage to make Dashman a commercial success.

    I collected several hundreds of email addresses over years of people interested in Dashman. Yet it failed, nobody bought it.

    How can a product show that much demand and have no sales?

    I’m purposely not telling you what Dashman was, because it doesn’t matter.

    I think the problem is that Dashman had a demand curve with a shape I didn’t predict. People would find themselves needing Dashman to solve a problem and would happy become a subscribing customer if Dashman was right in front of them… but… and this is the important part…. if Dashman wasn’t, they would find a workaround and not need it anymore. If I came a year later with Dashman they would buy because the workaround was working and switching was not worth the effort because their current pain around this issue was 0.

    Dashman solved a pain that generally stayed around for a couple of weeks and then disappeared. It didn’t matter if the pain was intense or not, it went away. You know what market behaves like that? Weddings. If you have a great idea for a product for Weddings and you spend 5 years collecting people that want to use it, once you release it, how many would start using it? Maybe the last couple of months of interested people. Everyone before that is already married and your product is worthless to them.

    I have heard weddings being a bad industry to work at but in all the books about building products in which they tell you to find the customer first I never read “make sure your demand doesn’t dissipate with time“.




  • Buying tools

    by

    I have a few maxims when it comes to buying tools. One I heard from Adam Savage and I think he heard it from someone else. When buying a tool you haven’t used before:

    1. When buying a tool you haven’t used before, buy the cheapest possible working version. Not the toy one, but the next level up.
    2. Once you wear it down, break it, outgrow it, buy the most expensive one you can afford.

    The idea here is that the cheapest one will be enough to get you started and learning about the tool, maybe it’s the wrong tool, or maybe the path splits in two or maybe you end up just not using it that much. By the time you are done with the cheap one, you will have gain knowledge that lets you chose a better one.

    When you buy a better one, it’s cheaper to buy a for-life tool, than keeping buying it every now and then. At that point the extra quality might also be appreciated, specially around precision and accuracy.


    I recently had to choose which family of battery based tools to buy into. Generally when buying a tool, brand-loyalty is a liability, not an asset. Buy whichever tool matches you the best for your need for that tool, whether it’s quality or price. But when it comes to battery there’s an advantage in brand-loyalty because you can interchange batteries between your tools. It would be awesome if there was a standard of battery connectors but that will never happen.

    I’m a hobbyist and I do some home repair and DIY, so my demanding on tools is not that high. I do love quality but I found something that I love more than quality: variety. I’d rather have an OK drill and an OK stapler than a great drill. This actually happened recently and we bought the stapler and now we find so many uses for it. Having a large repertoire of tools helps find new paths, new projects, new ideas. When it comes to battery tools, I’d say, buy the cheapest ones that are good enough for you.

    Big caveat: if it’s for a job that has a fixed set of tools, then adding variety beyond the tools you need is worthless, so there you should ramp up quality instead.

    This was my decision with battery tools: the default is Ryobi, they are cheap but not too cheap and they have a great range of tools. If we outgrew a tool, for example, not enough power, or not enough resiliency, then we upgrade it to Makita and have two battery families, but no more than two. The decision on Makita is not final, I would probably reevaluate it when the time comes… so far Ryobi is performing really well.




  • I’m very proud of what I achieved at Wifinity

    by

    Disclaimer: I’m blatantly tooting my own horn here because I’m proud of what I achieved, and very proud of what my team achieved. This is a personal story and a shout out to some awesome people.

    Today Jordan Bundy, someone I hired when I was at Wifinity sent all of us this message (pic included):

    Happy 1 year anniversary of getting the band together

    Jordan Bundy
    Part of the Wifinity team having dinner on our first get together.

    Today is the one year anniversary of the Wifinity software engineering team meeting face to face for the first time. I built this team completely distributed from the start and once I had the phase 1 complete, after months of being team mates but never having met, we had our first get together. Everyone was flown to London, where Wifinity is based, and we spent a week working, doing design/architecture, talking to all heads of departments, getting to know each other, and having geeky fun.

    Might have been the best business trip I’ve been on.

    Jordan Bundy

    What geeky fun? We all went to Bletchley Park to learn about code breaking during WWII and the birth of computers (where else?):

    On the day we all met, everybody was joking and talking as though we were old friends, like we knew each other already. I was ready to play host, to be the ice breaker, to work hard to make people comfortable… I ended up having to work hard to keep up instead. 

    At Wifinity I was in charge of all the technical aspects of a big Intellectual Property acquisition that had many moving parts that needed to come together in a 6 month program. We collectively wrote many hundreds of thousands of words of documentation that ended up being indexed, searched, tidied up and so on.

    The hardest part was probably migrating all of the servers from one company to another with minimal disruption to the wifi users. My goal was to have 100 or less complains and would have given us all a pat on the back for less than 10. In the end we got 0. Well… actually in the middle of the server transition we got 1 complaint, but turned out it was for a competitor service. That was pretty funny. A lot of credit for this migration goes to Chris Nash and Sam Whannel. If you need an SRE/DevOps/SysAdmin/SysOp type of person, you can’t go wrong with them.

    On the software development side the team did a marvelous job at taking over a very old code base with lots of technical debt, a lot of problems.

    Goran Jovic focused on security and he found some nerve wracking issues that we scrambled to fix. I remember internal conversations at Wifinity discussing pentesting; I think having Goran on the team was better than most pentesting.

    While we patched those security fixes, Rémi Sultan built an entirely new reusable authentication system that matched the needs of the company so that an entire class of bugs would be unlikely to ever happen again. He didn’t do it because it was on the roadmap but because he felt strongly about having a robust product, and he was correct.

    On the frontend side of things I had the pleasure of working with Grzegorz “Greg” Pabian. He’s an expert at many things. He was our resident Git wizard, teaching everybody the black arts of advance git and helping us when we got stuck with a broken branch. He could also have big-architecture thinking on the frontend so when he started re-writing and modernizing code, what he produced was a thing of beauty.

    Jordan Bundy also started on the frontend but it became clear to me that he’s a talented generalist. He didn’t stay on the frontend, he ventured into the backend and beyond, working with stakeholders. When I was leaving Wifinity, I recommended him to take over as manager of the team.

    And on the QA side of things I worked with Twayne Street. He’s good and fast at testing software. He would find so many rare bugs and his reports were so detailed and helpful. He started writing an automated testing system for Wifinity that looked pretty good. I really wish I would have seen it come to fruition.

    I’m very proud of what all of us achieved together at Wifinity and I miss working with this team a lot. I’d happily work with them again, and I know they would me; until then I’ve gained some very good friends. And I’m taking suggestions for our next nerdy venue. 

     




  • Good bye LastPass

    by

    I’ve been using LastPass for 7 years or more and I have converted various business and people to use LastPass but that ended today. I’m a security minded person so I’m not abandoning passwords managers, just LastPass.

    A few days ago I woke up and my LastPass vault looked like this:

    That looks bad… I contacted support which took about a day to tell me “Oh, yeah, your Vault is corrupted, don’t worry about it, we logged you out and fixed it. Just log back in.”

    Pfiuuuu! I thought. That was a nerve wracking unproductive day, but at least LastPass support eventually showed up and fixed it…. NOPE!!!! It was still corrupt. I sent about 30 more emails to LastPass over a period of 4 days after that and I got no response.

    I did manage to revert my vault back to the last master password I used, which thankfully wasn’t changed so long ago so I didn’t lose that many passwords and also thankfully I still remember that master password. But this is completely unacceptable behavior from LastPass to a paying user, so that’s it, I’m done with LastPass.

    Any recommendations on password managers?




  • First some definitions:

    • Bad debt is debt that was incurred for a liability, for example, buying cars, throwing a party, buying a boat, going on a trip.
    • Good debt is debt that is used to buy a producing asset. Debt used to start a business that is producing profit, buy a property that produces rent, etc.

    I once asked a bank for a loan. The loan would have been given to me on the basis of my salary, track record in earning money, credit report, and current affordability level. Still they asked me what I was planning on doing with the money and I told them I was planning on investing them in one of my business and on that basis the told me that I was rejected because they don’t do business loans. Mind you, I wasn’t asking for one, I was asking for a personal loan.

    Naively hoping to still qualify I explained that my business was buying property abroad and that it was a really good deal. Their answer was that I should talk to the mortgage department because they don’t do loans to buy property because then the property could be mortgaged and lost and they are left with nothing (nothing except every single payment coming out of my salary, mind you).

    When I talked to the mortgage department they told me what I expected: they can’t offer mortgages abroad.

    Later on I went to the same bank, I asked for the same amount and I told them I was planning on blowing it all out on a party. They said yes. Now that I was planning on just spending it on one single event of which no good financial outcome could come out, my salary was good enough for them to say yes to the loan. I asked what if I wanted to spend it on a highly depreciating asset, like a car, and they also said yes.

    It seems like banks prefer you to have bad debt, than good debt. I don’t know why it should matter one way or another if the collateral is the salary, not the asset, but if it matters, why does it matter in the wrong direction?




  • I once got a job at a company that was acquiring a massive piece of intellectual property from another and it was my task to build a team to maintain and transition the knowledge as well as running assets (servers, databases, etc). The company that hired me had no relevant the documentation and the IP we were buying came with very little and all potentially obsolete. Everything was a matter of asking random people one after the other piecing together the puzzle until the answer was built. Oh… and I had 6 months to get it done.

    The process of starting to write documentation was very daunting, so I created a new type of document that I named “Exploration”. An exploration is frozen in time and describes something that happened, was found, discovered, figured out, etc. For example an exploration might say: “My boss asked me to add an account, I didn’t know we had accounts. I asked Johnny and he said Sally used to do it but she left. I asked my boss who replaced Sally and I was told to talk to Sam. Sam told me how he adds accounts, the steps are 1, 2, 3, 4. He doesn’t know what step 3 does but he knows that if you don’t do it, the account doesn’t work.”

    An exploration is frozen in time and describes something that happened, was found, discovered, figured out, etc.

    I bet I’m not the first one to come up with this concept, but I haven’t seen it anywhere. Have you?

    The goal of the explorations is to quickly form a written corpus of documentation about “How do we do things here?”. This allows you to depend less on people, which is very useful during transitions or turbulent periods where people might leave.

    One of the key aspects of explorations is that they are narrative, informal, and not necessarily high quality. It’s hard to write the manual so people don’t do it. Specially if it’s a big manual of which nothing is written. The exploration is a brain dump.

    Explorations should be stored in a centralized documentation system that’s easily searchable. My preference is Confluence (maybe using the blogging feature), the cool kids are using Notion these days. Stay away from Google Docs, because it promotes private copies and there’s no way of having a single tree or directory of documentation. Being able to easily search all explorations is very important and they should be searchable with the rest of the documentation.

    Explorations sometimes evolve into proper documentation, procedures that are maintained and live. When that happens, I often have a See Also section in the document that points to the explorations that influenced it and at the top of the explorations I add links to the document. It’s important to note that explorations are tier 2 documentation and it’s important that everybody knows it so that they are not taken as truth when read and are written liberally.

    The frequency at which explorations are created changes depending on what’s going on at the company, but generally people should be writing them any time they faced something puzzling. The way I do it is very simple: I constantly debrief with my team about what they did and after they told me the story of what happened, what they did, the workarounds and we have a good laugh, I almost always say: “Please, write an exploration about it”. It takes some effort to get started, but I think often people realize not having to remember things and just making brain dumps has a lot of value. Eventually they would just write explorations without me asking.

    Don’t expect explorations to have an immediate effect. It takes time to build a corpus of data that is worth searching for answers. It might take you a year to get there.




  • A manager should multiply, not add

    by

    If you are managing a team of people that are transporting rocks from A to B and you spend one hour picking ups rock from A and dropping them on B, you added one hour of work. If you spend that one hour procuring wheeled carts so that people don’t have to carry rocks on their backs, you increased their performance by 25% (and happiness). One task makes you an adder, one makes you a multiplier.

    And this is very semantically correct. If your team has 0 people, increasing 25% of 0 is still 0. Your effort was wasted.

    If you are a multiplier, the more people you manage, the more impact you have. That’s why often the compensation of a person at the top of a huge organization is so big (not to say that current CEO compensation is correct, that’s another story).

    I find this is a good heuristic to know if I’m working on the right thing as a manager. Am I adding or am I multiplying? Sometimes I have to add, but if all I do is add, am I a manager?

    The output of a manager is the output of the organizational units under his or her supervision or influence.

    Andy Grove, High Output Management

    Something to keep in mind is that multiplying is hard. Well, it’s hard to find the opportunities when you can multiply. You need to sit down, look at the team carrying the stones, think about a better way, go find some carts, get a quote, evaluate it, run an experiment, see the increase in performance, discover not everyone knows what to do with it, write the manual and the training program, stop everyone from carrying stones (temporarily dropping productivity) so they can learn to use the wheeled carts.

    If as a manager you are so busy with interruption work that constantly lands on your lap, busy doing adding work, you will not have the time and mental space to think and find opportunities to multiply. This is why I don’t like the always-busy CEO or always-busy manager. When do they do their thinking?

    If you want to learn more about this I highly recommend Andy Grove’s High Output Management.




  • Quick definition:

    A standup is a type of meeting commonly done in software development teams and now expanding to other knowledge working teams. During the standup meeting you say what you’ve done, what you are planning to do, and whether you need help or are blocked. Normally they happen daily and they are called standups because traditionally were supposed to stand up in front of your desk and just share with everyone else. The idea is that by standing up, people would be brief… that is often not the case (I worked at a place where standups would take between 20 to 60 minutes for about 6 people).

    The idea of the standup is that the whole team is on the same page, but in my opinion, most developers zone out until it’s their turn, they say their bit, and then they zone out again. The only person paying attention to everyone is the manager. And generally there’s nothing bad with that except that we are wasting people’s times.

    There’s a problem with the standup though, which is, at what time is it supposed to happen?

    • 9? too early for most developers
    • 10? ok for most, but those that show up at 9 will do nothing until the standup, because why bother getting in the zone if you are getting to get pushed out of it.
    • 11? now almost everybody spends most of the morning doing nothing because of the upcoming interruption
    • 12? just before lunch? maybe… at least people will keep it brief! But those that eat later will get annoyed by the interruption.
    • Any time in the afternoon? are we talking about today/tomorrow instead of yesterday/today? most people don’t plan tomorrow’s work and thus the what-will-you-do? part will be of low quality. Oh… and those that are not morning people will get their most productive time interrupted.

    The solution is very straightforward: asynchronous standup. People just give a brief report to the manager, but in a public space, about their plan for the day and what happened yesterday. I guess you could do it face to face, but that’s awkward. Text asynchronous standup are much better and they are friendly towards distributed work. They have a second advantage: track record.

    The standup is one of my most useful tools for management. I don’t expect members of the team to read each others report, but they are all public. If I notice a conflict or a potential synergy, I may ask someone to look at someone else’s report.

    If I don’t understand something, I drop a question. If someone has been working on the same thing every day for too long, specially if they mentioned they were close to finish, I have a chat with them (could be a task is problematic, blocked, a drop in performance, etc). If someone is planning on doing something that shouldn’t happen, I jump immediately.

    As a manager, it’s yet another opportunity for me to give encouragement to individual members of my team about their work, to thank them for doing the crappy tasks that nobody likes, etc. I sometimes push myself to do that, because otherwise the standup could start feeling like a useless bureaucracy, writing something that nobody ever reads, a thankless task. I want my team to know I’m reading it, paying attention, finding places to help, etc.

    I generally use Slack for text communication for my teams and my favorite app for asynchronous standups in Geekbot. It’s good if you are together, essential if you are distributed.




  • This is an essential tool that every worker on a distributed team or company should have, no exceptions: a headset. Let’s explore why.

    When working distributed you are going to be having a lot of calls and the quality of audio is important. All meetings are tiring the same thing work is tiring, but bad audio is a divider. The worst the audio is, the shorter people can sustain the attention to complex meetings. Not only that, but the cognitive load generally means that people get cranky, irritated, tired and that means wasting productivity.

    You want the audio of the other person to come directly to your ears. That will help you understand and hear, but also it will remove any chances of the audio getting to the mic completely removing the chances of any echo. Yes, software can kill echo, but generally that adds awkward micro silences at the beginning and end of someone’s speech that are very tiring.

    You want the microphone right in front of your mouth to avoid capturing your environment’s noise, the cars on the street, the AC or fan, the children on the patio (or your lap), the cat running around, etc.

    This formula is not new, it’s what we use in environments that are so noisy people can’t talk to someone sitting next to them and so critical that miscommunication can mean death, aviation:

    Just copying the aviation headset form factor is a good place to start.

    FAQ

    Can I use my laptop’s speakers and microphone?

    The microphone tends to be bad, capture audio from the speakers, generating echo, or vibrations from the cooling fans making a buzzing sound that can go from annoying to overpowering depending on the laptop and frequently they are omnidirectional making any tiny noise on your environment really loud.

    When someone uses a laptop I feel they don’t care about anybody but themselves. Everybody has to put up with their shitty audio while for them it’s just fine.

    What about headphones and my laptops or phone microphone?

    That’s a bit better, at least there’s no echo, but buzzing and background noise as well as bad quality voice are still there.

    What about my phone?

    The mic and speaker tend to be of poor quality and limited processing power on the device mean more frequent artifacts, but at least there’s no echo nor buzzing. Depending on the phone, the mic could be quite omnidirectional though.

    What about the phone in loudspeak?

    No… that’s almost as bad as the laptop.




If you want to work with me or hire me? Contact me

You can follow me or connect with me:

Or get new content delivered directly to your inbox.

Join 5,054 other subscribers

I’m writing a book

Stack of copies of How to Hire and Manage Remote Teams

How to Hire and Manage Remote Teams, where I distill all the techniques I’ve been using to build and manage distributed teams for the past 10 years.

I write about:

announcement blogging book book review book reviews books building Sano Business C# Clojure ClojureScript Common Lisp database Debian Esperanto Git ham radio history idea Java Keep on Posting Kubuntu Lisp management Non-Fiction OpenID programming Python Radio Society of Great Britain Rails rant re-frame release Ruby Ruby on Rails Sano science science fiction security self-help Star Trek technology Ubuntu web WordPress

I’ve been writing for a while:

Mastodon