^{This is a revised version of an this earlier post, updated with new insights.}

“Fresh Ideas” Friday

It always happens on Fridays, and it goes like this: some team members have scribbled schemes on the whiteboard and are discussing a new product feature. There’s energy in the room, eyes shining with excitement, and I get caught up and join the party. Inevitably, 45 minutes later, we’re convinced this is the one feature that will take our software to the next level.

Of course, everyone knows about the ‘Mom Test,’ and in the back of our minds, we dread that we need to get customer justification first. But still, it wouldn’t cost us that much, right? The rockstar developers even guesstimate they get it done in a day or two.

That’s the time reality sinks in. I know, the team knows, and certainly, the rockstar developers know that things are never really ‘done’ in a day or two. I’ve struggled many times to convince the team that we should do proper product management and planning. I remind them about the other times we went all in new features only to learn a few weeks later we should have done our homework. It sucks having to bring the team around the whiteboard back with their feet on the ground.

I tried many things in the past to make the team realize the true effort it takes to create a new feature. What works best is something I call the ‘puppy dog dilemma.’ Seeing a cute puppy for the first time is always exciting, but adopting it means many years of responsibilities. Below are tips on how to ‘value’ a feature and how to do the ‘completeness’ check when estimating the effort. Also, when can we — and when should we — deviate from this strict discipline?

The forgotten questions

If you’re managing a product roadmap, I assume you know what you’re doing. Like you, I don’t just need answers; I need assurances to questions like:

• How many new customers will it bring in?
• Will it reduce churn?
• By how much can we increase our license fees?

It’s surprising (and when I see the faces of my team members, sometimes painful) how few new feature ideas survive these simple questions:

• Did anyone ask for it?
• If not, did customers ask for something else, but this would be the answer? (*)
• Can our sales team learn about it, or if you’re in SaaS, is it such a valuable improvement that we should redo our online demo scripts?
• Are the customer decision-makers (the ones who decide if money will be sent to our bank account) impacted by this new feature?

(*) By the way, this is perfectly okay. It’s our job as product developers to define our roadmaps—not just say yes to every implementation request from customers but rather design features that solve the underlying root problems (see Henry Ford’s “faster horse” analogy, although it seems he never actually said it: Harvard Business Review article)

The checklist no one talks about

The reality is that new features bring with it a checklist — a list that seems to grow longer with every release. And yet, in the excitement of the moment, I have often forgot about it. This checklist isn’t just about coding; it’s about the ripple effects that any new feature will have on the ‘whole’ product.

• What about updates to our tests?
• What about backup and restore scripts and processes, logging, or even installation scripts? These things are rarely top-of-mind when the idea is fresh and exciting, but they’re essential in the definition of the ‘done’ status of a new feature story.

Less obvious but also critical:

• Does this feature impact any legal documents (Privacy policy, GDPR compliance, or ToU)?
• Translations (in case you support multiple languages)?
• User training, FAQs, and internal documentation.
• Customer support?

We may need to integrate the new feature into onboarding materials, updating automated workflows, monitoring and analytics, or even considering how this change might impact SEO or page load times.

It’s exciting to build something new, but these details can make or break the success of a feature. Ignoring them means risking a feature that feels half-baked or causes headaches down the road. So we need to run every new idea through this ever-growing checklist and make sure we’re not just adding another puppy without understanding the responsibilities that come with it.

Never waste a good crisis

Early in my career, I noticed how some managers seem to thrive on a good crisis. You know the type: the crash on December 26th justifies calling the team in on short notice to fix a critical problem. There always seems to be time and budget to repair things (during the Christmas break) but never time to solve the root cause of the issue (early January during normal work hours). When I became a team lead, I wanted to avoid that and created a public list titled: “Things that will one day come back to haunt us.” We keep a list of weak spots in our product and operations that one day could be the reason for a midnight crash.

The team realized I was serious when I gave them the authority to allocate a minimum number of story points to tackle the most urgent items from the list. We know the payback period is measured in months, but I can guarantee you will see the impact in terms of better stability, fewer crashes, and hopefully no data loss or security breaches.

If your backlog list is growing, you don’t talk enough with your customers

I’ve written before that product backlogs tend to become longer all the time. More ideas are added to the list than you can ever implement. In a previous blog post, I mentioned that you should accept this and learn to live with it. However, after reading the title of this paragraph in another blog post, I realized that this might not be the right approach. It’s ‘out there’ in the real world where our product succeeds or fails, not within the walls of our office.

There are many techniques to ‘value’ new feature requests. Determining the Return on Investment (ROI) of a feature helps estimate the payback period for the investment. I’ve learned to be very cautious about returns that take too long. A lot can change in six months: customer reorganizations, new technology, shifts in the economic situation, and even changes within your own team.

Not all feature requests can be calculated: improving usability or making the app faster impacts the experience of the end-user, who might not be the person deciding on budgets and upgrades. Yet somehow, focusing on these improvements feels like the right thing to do.

Print this picture

Building great products isn’t about adding more features; it’s about adding the right ones. I’ve been caught up many times in the excitement of new ideas, the pressure to keep up with competitors, or the desire to make people happy. But product management means:

• saying no more often than yes,
• getting out there and talking to users,
• keeping the ‘new feature checklist’ updated, and
• setting aside time to avoid disasters.

I printed a picture of a cute puppy and hung it on the wall. When relevant, I point to the ‘puppy dilemma’ picture to remind us to consider all the potential costs and benefits before making a decision. Hopefully, this helps you decide what to work on. Please share your comments and feedback.

The first time I came across a “Most Favored Customer” clause in a contract proposal, I was totally confused. I had no clue what it was about. It usually looks something like this:

“Vendor agrees not to treat any customer (including (names)’s Affiliates), better than (name) , and agrees that (name) will be afforded prices, warranties, benefits and other terms that are no less favorable than those offered to Vendor’s other similarly situated customers.”

Wait, what?

My first reaction was sheer amazement: are they actually writing into the contract that they want special treatment? Not only do these big companies expect the best service you can provide, but now they also want it at the best price? And if any other customer somehow gets a better deal, they automatically get it too? I couldn’t help but think, “How do they even dare to ask for that?”

The Lazy Procurement Tactic

I’ve come to see this as a bit of a lazy move by your customer’s procurement team. With this clause, you’re legally bound to offer the best price so that no one can boast to your CEO/CIO/CxO on the golf course that they got a better deal. But in reality, things are usually more complicated than that.

Can You Say No?

For your customer, getting rid of this clause is usually tough since it often requires both legal and purchasing approval. The poor procurement soul you’re talking to will likely have to go back to legal if you push for a dramatic change to the standard contract — and we all know how unlikely it is that such a change will be approved. While some negotiation is always possible, I’ve found it’s hard to fully remove it. But as we’ll discuss later, verifying this clause is typically difficult, and you have the advantage of making it even more so. Ultimately, you’re in a stronger position.

However, if you do end up agreeing to it after some back-and-forth, make sure the deal is worth it. This can also be your chance to justify a higher price. Plus, it gives you one more point to negotiate over. Even if you know you’ll eventually agree to it, it’s another lever to use in the bigger negotiation.

What do you do in practice?

I regularly come across this clause in master service agreements and contracts. And after going through the whole process—negotiating, pushing back, throwing up my hands—I end up agreeing every single time. Why? Because when the contract value is high enough, it starts to make sense to offer that kind of preferential treatment, at least on paper. After my initial shock at the sheer audacity of MFCs, I’ve come to terms with it. It’s just something legal teams in big corporations do. Over time, I’ve realized that it’s not as big of an issue as I first thought because:

• These customers are so important and big that they’ll squeeze you anyway if they face budget cuts, management changes, or any other shifts. They don’t need a clause to push for discounts when extending your MSA. The Most Favored Customer clause usually isn’t my main concern.

• How can they even verify this? Each of these customers has such strict confidentiality clauses that I, as the vendor, can’t show one customer’s contract to another. In all my experience, I’ve never been confronted with this situation, but if it ever did happen, I’m confident I could wiggle my way out. Even if CEOs start comparing notes, the actual work agreements are usually so different that comparing prices wouldn’t make sense anyway.

• Every 100k deal is different and specific. It’s not like there’s a standard price list that makes comparing different offers easy. As your company grows and your product matures, your contract values will increase as well. But keep in mind, this applies to high-value deals like these. For smaller ticket prices, you won’t want to negotiate contracts like this.

If your prices are listed on a pricing table on your website, you typically can’t agree to these clauses. Website prices are usually set so low that you can’t afford to spend time negotiating over them, let alone pay a legal professional to work on it.

These MFC clauses are meant for contracts where each customer has a unique price and terms. You can explain to new prospects that earlier customers received better deals because they invested time and took a risk when your product was less mature. This allows you to exclude existing customers from the MFC clause without having to name them—something you’re likely not permitted to do anyway.

In conclusion, don’t be as shocked as I was when you first come across this in a contract proposal. Take a moment, breathe, and remember that there’s more to this story than meets the eye. This is just one of many elements you’ll need to discuss in the negotiation, but deep down, you’ll know you’ll most likely agree to it. And keep in mind that the poor procurement soul at your customer is just doing their job, following the playbook. I hope my experience gives you some perspective when you eventually face it.

Over the past few months, I conducted 10 user interviews and spoke with many more people about how they use note-taking tools like Notion and Evernote. Each person has unique habits and preferences, and the variety is striking. Some manage vast collections of notes, while others use these tools as personal CRMs. I’ve talked to people who are very happy with a note-taking tool that holds just about 100 notes. On the other hand, some users have about 30 gigabytes of Evernote folders and 55,000 notes, which is absolutely mind-boggling.

Here are some quotes I noted during the interviews:

On organizing notes

“These things can be messy, my organization can suck, but it needs to be in one place. I have my emails, documents, notes, web clippings, and bookmarks. It’s really an issue if I don’t know where to look for them. If everything is in one place, that’s already a very good start.”

“Nah, I don’t do tagging. It’s too much work. The AI should take care of that.”

Saas or on your local disk?

“If this is my second brain, it cannot be on somebody else’s server.”

“I don’t mind where it is, as long as it works. That’s okay.”

Use on mobile?

“I have everything on my server. Why would I have to use it on my mobile?”

“For mobile, speech-to-text is the only thing I need… My voice recording should appear automatically in my to-do folder so that I do not forget it.”

Information management

“What I need is ‘Linking my thinking’.”

“My notes are my personal Wikipedia.”

As a conclusion…

People use note-taking tools in very different ways. There is no one-size-fits-all solution. That explains why there are so many tools in the market and it is not possible to define ‘the best’ tool because that depends a lot on your personal requirements.

The tempation is great to then just develop my own very specialized and very personal note taking tool. I would not need to do any user interviews, because I can interview myself and doing user interviews will undoubtely lead to conflicting requirements.

Besides all the complexities of managing a software product company, there is another challenge many companies face: ensuring they can pass audits. Especially in regulated sectors like pharmaceuticals, this can literally be a show-stopper if you are not prepared. Our approach to this challenge is to be ‘always audit-ready,’ and that has proved to be a game-changer.

Identifying core processes

The transformation began with identifying our core processes. We pinpointed around 17 key processes that constitute the majority of our work. This step was crucial because it allowed us to focus on which processes are essential for our operations.

Creating checklists for each process

We then created specific checklists for each one. Checklists are straightforward, prevent tasks from being overlooked, and bring a sense of clarity and direction. In our case, these were particularly designed to keep us audit-ready for our yearly ISO audits and other unplanned customer audits.

Integration with tools

We integrate these checklists into GitLab. This integration is vital as it enables us to track every action on the checklists, creating an automatic audit trail of who approved what, and at what date and time. It not only promotes accountability but also provides a clear record for audits, simplifying what was once a complex process.

Wiki for team knowledge

For knowledge sharing and management, we opted for a wiki structure. It’s particularly helpful that you can step in and out of the process documentation during an audit, showing the auditor the process steps we have set up.

Real-life application

Implementing this system has had a profound impact. For instance, our software release process, which sometimes was a bottleneck, became more streamlined. The checklists integrated into our version control system reduced errors and made auditing processes more straightforward. It seems almost magical to auditors when they realize they are looking at actual system logs of what happened, timestamped at the exact moment it happened. It alleviates their suspicion that perhaps all these logs were filled in the last month in preparation for the audit.

Balancing Flexibility and Structure

It’s important to balance the rigidity of checklists with the need for flexibility. We made sure our checklists were guides rather than constraints, and we continuously adapt them based on team feedback and improved or changed processes.

Benefits

The formal benefits are

• Efficiency in Operations
• Ease in Audit Preparation
• Improved Knowledge Management

But the real caveat is that the easiest way to get things done is the compliant way : every team member has a clear inventory of what needs to be done, and completing the checklist also creates the necessary logs for the audit trail.

Conclusion

Once the 17 processes above were defined, there was much less discussion on how things should get done or get approved. During retrospectives, risk analyses, or bug post-mortem reviews, we go through our processes to see what we have missed or what can be improved. This results in a process update and a parallel checklist update.

Some time ago, I discovered Dokku — an innovative open-source tool that transforms your own server into a powerful deployment platform, akin to Heroku or Render.com. Let me share what I learned and explain why Dokku might be the solution to a problem you didn’t know you had.

How to get started

I recommend starting with a simple Rails ‘Hello World’ application. This approach allows you to concentrate on the deployment process without the complexities of setting up and connecting to a database, running database seeds, and so on.

To begin, I reset my VPS, a modest 1GB instance running Ubuntu v20. The next step was installing Dokku, and after some time, my Ruby on Rails app was live on my own server.

Redeploying new versions

Redeploying a new version of your app works similarly to how it does on Render.com or Heroku. A simple “git push origin” to your VPS (your remote server) triggers a rebuild and redeployment.

The real magic of Dokku lies in its seamless deployment process, which ensures zero downtime for end users. Dokku achieves this by keeping the old instance of your app running until the newly deployed instance returns a 200 response code on its app/up page and is ready to go live, ensuring a smooth transition.

Time is money

This is a great experience; deploying apps directly to a server under my control, without reliance on external platforms, offers freedom and significant cost savings. However, it’s important to remember that time is money. Of course, time spent tweaking Dokku settings is time not spent on developing new features or acquiring new customers.

Using platforms like Heroku or Render.com involves costs for

• app deployment,
• a database, and possibly
• a service like Redis.

These costs can escalate, especially when deploying multiple apps.

Consider the extensive details on Heroku’s pricing page. I believe these funds could be more effectively allocated to your VPS, should the need arise. If you require additional capacity, simply upgrade to a higher tier for your VPS, or, for particularly resource-intensive applications, migrate to a dedicated server equipped with its own Dokku installation.

Scaling up your app(s) and multi server support

If you would ever reach the capacity limits of a single server, Dokku offers an official k3s core plugin that facilitates the transition from single to multi-server setups. This plugin leverages enhancements in other areas of Dokku—such as the proxy layer, cron integration, and registry support—to deliver a simplified Kubernetes experience, enabling you to deploy your application across multiple servers easily.

Other great features

Dokku has 2 other features I found very useful:

• Let’s Encrypt integration for easy HTTPS setup and
• the capability to link a specific domain name to each of your apps running on a single server. I have successfully linked several domains to different apps on my server.

Alternatives

While Dokku is open-source and free to use, there’s also Dokku Pro—a premium version with a graphical user interface, priced at around $850. This version enhances the Dokku experience with a GUI and supports the project’s maintainers. It’s a sound investment for those deeply invested in Dokku.

Alternatives like Hatchbox.io by Chris Oliver from GoRails.com (a paid service) and Kamal (open-sourced by 37signals) offer unique features. However, I chose Dokku for its simplicity and efficiency, which perfectly aligns with my needs.

Is it difficult?

Dokku provides an efficient alternative, functioning as a thin layer on top of Docker. It demands minimal Docker knowledge for successful app deployments.

This post encourages you to explore deploying your apps on your own VPS. Expertise in system administration isn’t necessary for success. If I managed to get comfortable with Dokku in just a few days, you can too.

Interesting links

• Official documentation: https://dokku.com/docs/getting-started/installation/
• Hackernews post: https://news.ycombinator.com/item?id=31376241
• Dokku vs Kamal: https://deploymentfromscratch.com/tools/dokku-vs-kamal/
• Hatchbox.io: https://hatchbox.io/

Interesting blogposts:

• Deploy Rails Dokku - Alan Vardy
• Deploying Ruby on Rails with Dokku, Redis, Sidekiq, ARM Docker & Hetzner - RailsNotes.xyz

^{Image by macrovector on Freepik}

Data modeling is often a somewhat underrated discipline. I’ve had the privilege of collaborating with numerous development teams. A recurring surprise was that many of these teams, despite managing substantial databases with 50 upto 100 entities, often lacked any form of visual representation of their data models. This absence of visual documentation—be it on paper or displayed prominently on a wall—strikes me as a missed opportunity for clarity and organization.

The Necessity of Documentation Strategy

My experience with applications of around 100 entities—or even several times that number—has taught me the critical need for a robust documentation strategy. Such a strategy enables the segmentation of an expansive model into digestible sub-models aligned with the application’s various domains. These sub-models, essentially logical views, don’t manifest in the database; instead, they represent a conceptual organization where tables coexist side by side.

Logical vs. Physical Models

It’s worth noting that many data modeling tools differentiate between logical and physical models. The former offers a broad overview, whereas the latter delves into specifics tailored to the database technology in use. My approach leans towards minimizing the gap between these models, advocating for a logical model that closely mirrors the physical one. I belief that modern database technology’s capacity is able to handle optimization efficiently, rendering premature optimization less of a concern.

Active Record Associations and Navigation

Particularly in object-oriented programming languages like Ruby on Rails, the Active Record Associations is a powerful abstraction layer atop the physical database. To effectively navigate through these associations within an application, a clear, documented model is indispensable. Whether tracing the relationships from a user to their team, role, organization, or subscription, a visual or paper-based model facilitates understanding of entity relationships, including one-to-many and many-to-many associations.

Lessons from Working with Large Data Models

Embrace Formal Data Modeling Techniques

Familiarity with normalization principles and the avoidance of redundant attribute information across entities are foundational. Strive for a logical structure that mirrors the application’s logic without succumbing to premature optimization for perceived performance gains.

Design Considerations for Attributes

Beyond adding records, consider the implications of (logically) deleting data. For instance, the removal of a customer record could lead to the loss of valuable historical data, highlighting the need for strategic use of flags to manage data lifecycle effectively.

Adaptability in Modeling

The real-world application of a data model can reveal unforeseen requirements, such as a user belonging to multiple teams rather than just one. Addressing such modeling errors promptly—despite the challenges involved—is crucial for maintaining the integrity and usability of the database.

Conclusion

Data modeling, while complex, is an essential aspect of software development that in my view, needs more attention and respect. Effective data modeling facilitates a deeper understanding of an application’s structure, enabling developers to make informed decisions and adapt to evolving requirements. By valuing and investing in comprehensive data modeling practices, development teams can significantly enhance the robustness and flexibility of their applications.

Hi, I recently decided to switch from Evernote and I tried many alternatives. I found Obsidian to be the best alternative. There are 3 reasons:

• The idea behind the product,
• The product itself, and
• The product vision, which aligns well with my needs for note-taking and organization.

One nice thing about Obsidian is that it’s free, unless you want to use their sync feature. More about that in a minute.

A little bit of history

I have around 7,000 notes organized across roughly ten folders. That means that some of these folders are quite big – 1,200 notes in one notebook and 1,500 in another.

Back in the day, when I first started using Evernote, I made the error of creating too many notebooks. Only to backtrack later and consolidate those into a few large archive notebooks. These archives represent the different areas of my work and my personal interests.

Robust Tagging

To effectively manage my notes, I realized I needed to set up and maintain a good and robust tagging system. I’ve been quite meticulous about keeping it up to date. For example, here are my rules for every tag representing a real person:

• always have the correct spelling of the name, and
• begin with an ampersand sign, and
• follow the format @firstname-lastname.

Regular maintenance of these tags is a key part of my routine. I make sure to merge any duplicates and remove tags that no longer have notes associated with them.

Currently, I have ended up with 1,100 tags.

Export/Import insights

When converting from Evernote to Obsidian, I learned several important lessons and identified some key areas to be cautious about. These are:

1. importing tags
2. importing ENEX files
3. working with PDFs
4. import html emails
5. how to set up a workflow

We handle these below in more detail.

1. Tagging challenges and solutions

One of the main challenges I encountered was with the text of my tags. In my Evernote system, I relied heavily on tags, often more than notebooks, to organize my information. However, when importing these into Obsidian, I ran into some issues.

Tags containing special characters were not recognized as valid in Obsidian. These would appear in red within a note, indicating a problem. The problematic characters (that I found) included:

• Ampersands (&)
• Parentheses ( ( ) )
• Dots (.)
• Plus signs (+)

Also, any tag with a slash (/) was interpreted by Obsidian as a parent and child tag combination, which wasn’t my original intent in Evernote.

To resolve this, I wrote a simple Ruby script. This script looped through all folders and markdown files, converting these special symbols in the tags into dashes (-). Since the notes in Obsidian are just files on the local disk, looping over them and modifying the tags was straightforward.

After replacing these special characters, the tags functioned correctly in Obsidian, and no data was lost in the transition.

2. Importing ENEX Files: better not all at once

I used the Import add-in provided by Obsidian to import my notes. When you export your folders from Evernote, these are saved as individual ENEX files, one for each folder. Initially, I attempted to import all these ENEX files simultaneously using the add-in’s ‘Import folder’ button.

However, importing all folers at once turned out to be a mistake. A few days later, I realized that some notes had been misplaced into the wrong folders. Fortunately, no notes were lost in the process. I had counted them before starting and after the import, and the numbers matched up.

To fix the folder misplacement issue, I had to restart the entire import process and import the ENEX files from Evernote one at a time. This approach proved to be more effective. Since I only had about ten folders, it was relatively quick.

Another hiccup during the import process was encountering seven error messages. These were due to the presence of special characters in the titles of some Evernote notes, which aren’t allowed in file names in Obsidian. Characters like semicolons caused these errors, and I had to address these individually.

3. Managing attached PDF files

Another key area to discuss is how I’ve been using PDF files. Over the past 11 years, Evernote has served as a sort of archive for me, especially for managing the administration of three separate companies, each with its own archive notebook.

These archive contain numerous PDFs - invoices, orders, contracts, and more. While handling accounting tasks, I often needed to search for specific invoice amounts mentioned in bank statements. Evernote’s ability to search within PDFs was incredibly handy for finding those exact figures.

However, I’ve discovered that this PDF search functionality doesn’t seem to be available in Obsidian (at least, I haven’t found it yet). While I don’t foresee this being a major issue in my use of Obsidian, the capability to search within PDFs would definitely be a valuable addition. There are community plugins to do that, but I am cautious not to do too much at once.

4. Handling HTML emails

I’ve extensively used Evernote for company administration tasks, which often involved managing invoices and bills received as HTML format emails. A convenient feature of Evernote is its ability to create a unique email address for you. When I forwarded HTML emails to this Evernote address, they were seamlessly converted and stored in my Evernote database. Additionally, any PDF attachments would automatically become attachments in the respective note.

However, this process changes when moving to Obsidian. HTML emails, when imported into Obsidian, are converted into Markdown. This conversion doesn’t quite capture the original formatting effectively, leading to a loss of clarity and recognizability in some documents, such as invoices.

To work around this issue in the future, I plan to first print these mails as PDF documents, and then attach these PDFs to notes in Obsidian. This method should help preserve the original format and content of the documents.

5. Note-taking workflow

In Evernote, my system included a “todo” folder, which functioned as a sort of inbox. Into this folder, I would place various items:

• Emails I sent to myself,
• Web clips I saved,
• Quick notes I jotted down.

Everything accumulated in this todo inbox. About once a week, I would sift through these items, usually finding between five to fifteen notes awaiting organization – which involved attaching tags and moving them to the correct folder.

However, managing notes in Obsidian presented a unique challenge, especially when it came to notes with attachments. In Obsidian, attachments are stored as files on your local disk, typically in a subfolder. When you move a note, the attached files aren’t automatically relocated with it. This means that while the note may move to a new folder, its attachments might remain in the original location. The links still work, but it can be disorienting to find the attachments in a different folder from the note.

As of now, I haven’t discovered a way to move notes in Obsidian along with all their attachments seamlessly. If anyone has tips or solutions for this, I’d greatly appreciate your input!

Sync feature

I eventually decided to use the sync features that Obsidian offers as a paid service, and I must say, it’s been a wonderful experience. This feature provides encrypted syncing, which allows me to seamlessly and safely sync my notes between my laptop and phone. It does cost a bit - I believe around $8 per month - but it’s been absolutely worth it.

The reliability of Obsidian’s sync feature really stands out. I’ve used it to sync all my 7,000 notes, and even after deleting and re-importing them, the sync process kept everything perfectly synchronized. No issues with duplicate or lost notes, which were problems I occasionally faced with Evernote.

In short, this sync feature in Obsidian has proven to be worth every dollar. It’s robust, reliable, and enhances the overall efficiency of managing my notes.

Conclusion

So, that’s my switch from Evernote to Obsidian in a nutshell. Honestly, it went pretty smoothly, way better than I expected and way better than all the other tools I tried migrating to in the past. Sure, there was that moment with the tagging system, but even that wasn’t too much of a hassle, especially with a little help from ChatGPT for the ruby script.

If you’re considering making the move to Obsidian, these are the key things you might bump into. It’s more about being prepared than anything else. If you come across any neat tricks during your transition, I’d love to hear about them!

_{^{Image generated with OpenAI’s DALL-E}}

Introduction:

Data privacy concerns typically come up in many sales conversations, especially in industries dealing with sensitive information. A common question that arises during sales calls is: “How do I know you won’t sell my data to my competitors?” This question is not just about legal assurances; it’s about trust and operational integrity.

A genuine concern

During a recent forum discussion, someone explained that his prospect raised this very concern. His startup is building a CRM for a niche market and one of his prospects asked following question: “How can I be sure you are not selling my contacts and my leads?”. He was surprised by the question and felt that he did not succeed in convincing his prospect.

The consensus in the forum leaned towards solving this concern by including a confidentiality clause in the contract. Many people explained they already had this in their standard agreements, so what is the issue?

But is that enough? A contract is a foundational step, but trust goes beyond legal documents. The post author suspected if the prospect felt unsure about the confidentiality of his data, he would not be persuaded by a contract clause.

The real issue: Trust beyond the contract

The real issue is about ensuring that your customers can trust you with their data. This trust isn’t built through words or contract clauses alone but through robust internal processes that safeguard their data. In my previous job as a CEO of a software company, I understood that access to sensitive data must be restricted and monitored, not just promised.

Operational procedures for data handling

• Limited access: Just like in the medical device company I led, access to sensitive data in any company should be highly restricted. Only essential personnel should have access, and only for critical tasks, and only after explicit agreement from the customer.

• Audit trails and approvals: Every access or modification to client data should be documented and audited. In cases where access is necessary, such as fixing a specific bug, the explicit customer approval is logged.

• Data encryption and anonymization: To further secure data, employ encryption and anonymization techniques. This minimizes the impact even in the unlikely event of a data breach.

• Transparency and audits: Transparency is key. Be open about your data handling practices and welcome audits from clients, or be ready to share audit reports from previous audits you underwent. This demonstrates your commitment to data security.

Note: there may be other (e.g. legal) reasons why data needs to be accessed, and the processes for handling these kind of requests are outside the scope of this post.

Conclusion

Imagine you’ve just bought a new wardrobe from IKEA. It looks great in your bedroom, and you’ve filled it with your belongings. Now, how would you feel if IKEA personnel could inspect what’s inside at any moment? Sounds absurd, right? This analogy surprisingly parallels the concerns many have about data privacy in the SaaS world.

Trust in data privacy isn’t just about what’s written in the contract. It’s a commitment reflected in your company’s daily operations and attitude towards data security. By embedding these practices into your business ethos, you assure clients that their data is in safe hands, beyond just a legal promise.

What are networkers looking for?

Recently, I attended a speed dating event and met several interesting individuals. One of them inquired about how I discover similar events. I think this might be valuable information to share.

Networking events available everywhere

• A few years ago, I participated in a Startup Weekend by Techstars. This event is an intense weekend dedicated to building a prototype and preparing a pitch. If you’re considering joining, be sure to prepare thoroughly for a time-limited pitch. Approach it as if it were a TED talk to attract a great team. Most presenters are underprepared and fail to finish on time, resulting in their ideas not being selected. Our team secured the second prize!

• Through BNI, I have attended several local networking events. These events are quite demanding, featuring weekly breakfast meetings at 07:30. Investing time and energy can add significant value to the group, and you’ll likely receive referrals in return. This is particularly effective if you’re interested in local markets. Note that most attendees are solo entrepreneurs or from small companies (less than 10 employees).

• I regularly search Eventbrite using location-based and keyword searches. It’s important to check the popularity of the organizer, as there are events that attract only a small number of attendees.

Belgian events

• Any event organized by Betacowork is worth considering. I plan to try their free coworking space offer to meet new people.

• Voka.be is an active event organizer attracting participants primarily from medium-sized enterprises. Interestingly, you can participate even as a non-member.

What Do People Look for at Speed Dating Events?

During my recent visit to the speed dating event, I was surprised to find that most starting entrepreneurs were primarily seeking two things:

• Sales profiles
• Venture capital

On my way home, I pondered whether focusing on a better product/market fit might make both these searches unnecessary.

There’s often a belief that bigger companies offer better and more reliable products. But is that really true? In this blog post, we will explore why small companies and even solo entrepreneurs often deliver more and better value than the big established vendors.

Contact a company not only to get support

One obvious advantage is that you can expect more personalized support, quick feature updates, and often, a product that is more in sync with your needs. Smaller companies typically welcome feature requests, especially if you take the time to justify why a particular feature might benefit the product. Of course, it remains at the discretion of the product owner to include this feature or not, but I have seen my suggestions end up in a product more than once.

Talk to the Decision Maker

The great thing is that you can get into contact with (one of) the owner(s), and it’s great to know that you are communicating with one of the decision makers.

I remember one particular request where I hadn’t really thought through how a particular request I had could work. At first sight, it seemed like a valuable idea, but the product owner got back to me. He agreed that it would be a great addition to the product, but he challenged me to draw up the GUI on how to set that in the app. In the end, I had to agree that it would make the product hopelessly complex.

Is it really more risky?

Some may argue that opting for smaller providers is risky. But think of all the products Google once had and now abandoned:

1. Google Reader: Launched in 2005, this RSS reader was popular but was shut down in 2013 due to declining usage.

2. Google Plus: Aimed to be a competitor to Facebook, Google Plus was launched in 2011 but failed to gain traction. It was shut down for consumers in 2019.

3. Google Wave: Launched in 2009 as a collaborative real-time editor, it was discontinued in 2012.

4. Google Glass: Initially launched with much fanfare in 2013, the consumer version failed to take off and was discontinued, although an enterprise version still exists.

5. Picasa: Acquired by Google in 2004, this photo-sharing service was discontinued in 2016 in favor of Google Photos.

6. Orkut: One of Google’s early social media efforts, launched in 2004 and discontinued in 2014.

The wikipedia page on abandoned Google products lists 61! products.

The reasons for these discontinuations vary but generally include lack of user adoption, shifting company focus, or the features being integrated into other existing Google products.

The Venture Capital poison

I’ve written before about the effect of taking VC money on companies. I argue strongly against going down that road as an entrepreneur. But what is the effect on you as the customer when your beloved SaaS vendor sends an email with the good news that they now have millions in the bank?

I’ve started to consider those emails as ‘bad news’.

Initially, all goes well. Product releases accelerate. Documentation improves. Support reacts faster. It’s clear that more people are being hired, and more work is getting done. This work was already overdue because, when cash was in short supply, difficult choices had to be made.

Now, remember that a VC is investing money in a company with the sole objective of getting a 10x or 20x return on their investment a few years later. Because no one, and certainly not VCs, can predict the future, they need to repeat this game with dozens of startups. One or two of those will become the hit they were hoping for and will make up for the losses in the other 90% of cases.

Then, all sorts of things start to go wrong: bad product choices, a focus on customer acquisition instead of investing in current customers, rising prices, and excessive hiring.

Here are some notable examples:

1. Jumio: An identity verification SaaS that raised $35.4 million, declared bankruptcy in 2016 due to financial irregularities. However, it did manage to restructure and is operational today.

2. Zirtual: A virtual assistant service that raised around $5.5 million and abruptly shut down in 2015.

3. LivingSocial: While not a traditional SaaS company, this online marketplace raised about $928 million in funding and was considered a significant player in the “daily deals” space. It had to undergo massive layoffs and eventually sold to Groupon for a small fraction of its valuation.

My personal list of smaller software companies

Here are some products that I use regularly and find extremely useful:

1. Workflowy: An organizational tool that allows you to create nested lists, making it easier to manage tasks, notes, and more.

2. ButtonDown.mail: A simple and robust newsletter platform aimed at making it easy to send out emails without the bloat of larger platforms.

3. MailPace: An email client designed to streamline your email management process, focused on speed and ease of use.

4. Kagi: A high-quality, 100% privacy-respecting search engine with results augmented by non-commercial indexes and personalized searches.

5. Plausible.io: A privacy-focused web analytics tool that doesn’t use cookies, providing essential metrics without compromising user data.

6. Rsync.net: Offsite backup based on the ZFS file system.

Let me know in case you have examples of your own that fit (or don’t fit) in this list.

Conclusion:

Going for a smaller provider doesn’t necessarily mean taking on more risk. Even giants like Google have discontinued many beloved products, leaving users in the dark. Smaller companies are more likely to value each customer, offering a level of dedication that can be reassuring. If you’re looking for software solutions that offer quality and reliability, don’t hesitate to check out smaller companies. I’ve shared a few of my favorites above. They may not have the big-name recognition, but what they lack in size, they more than make up for in value and customer focus.

Certainly here, big isn’t always better,