Home » process

Tag: process

Automation with Zapier

What do you value most? I hope that your answer is: “TIME.” 

Time is our most valuable resource because it is non-renewable. Wasted time is lost forever. And it could be argued that the reason we work so hard is to have enough resources. Resources that will allow us to spend more time doing the activities that we enjoy: activities like following your dreams, working on your business, spending more time with friends and family. 

I don’t know of any better time-saver in the online environment than automation.

Automation means to identify and formalize processes for the flows that make your business work and then use various tools to set them on “automatic.” This way, they can work even when you are not paying attention. It is like having an employee that is almost free and never sleeps or rests. 

In today’s world, the leading tool for automation online is Zapier. 

The idea behind Zapier is quite simple and yet profound because of the market they are speaking to. 

What happens is that in the online world of business, you have your website, your store, your payment gateway, customer engagement, webinar, emails, and so on. All these components need to talk to each other. What used to happen before, is that you, as the business owner would have to create and manually maintain this communication, usually based on email notifications you would get from various systems. 

The alternative was to hire someone to do it for you or hire a developer to write a custom program that would automate these processes. Both options could get pretty expensive.

There has been a shift in the past few years. Each of these services exposes an API. This API allows them to talk to each other in a clear and standardized way. With this option available, you would need somebody to integrate these APIs. To connect them in ways that make sense for your business. 

Here in comes Zapier! The beauty of it is that they have put together a platform that allows non-developers to visually express their processes and to connect all these components in a way that makes sense. This flow is testable (which is very important, you want to make sure that your automation works as intended), and you have analytics and an overview of what is happening.

There is a free tier for Zapier, but I want to get into the paid one because I think that is where the power is. You may shy away from paying them the monthly fee. So let’s explore that a bit. 

The way to think about choosing a paid plan is to make a business decision. Would paying Zapier a monthly free enough time and generate enough sales to cover for the costs and then some?

If you get their $20/mo plan, you need to only generate an extra $20/mo in sales for this option to make sense to you. But not only that. Also, consider the free time you now have to do something else, and how much you value that. Consider the money you would spend on a developer to set this up for you and then have it maintained. (By the way, I am not an affiliate for Zapier, I am just using them as an example to talk about automation)

In conclusion, we live in exciting times, where with a bit of patience and thinking through your processes, you can build your website and connect the required components with no need for a developer if you use a tool like Zapier. And this excites me because it enables even more people to express their creativity cost-effectively!

If you are reading this and you are a developer, then seriously consider exposing and API for your services and products and have them seamlessly integrate with Zapier. 

The New Normal – Collaboration Tools – Google Docs

A new era of remote work and collaboration is upon us. And it is time to build a “new normal” as we have this excellent opportunity for a reset. 

I have mixed feelings about Google, but leaving that aside, for now, let us have a look at their Google Docs platforms and how to use it to collaborate with your team. 

My idea here is to share with you what is possible so you can make an informed decision if this is something you can use to support your project and your people. If you do like these features, there are plenty of YouTube tutorials on how to use them. 

As you go through this keep in mind the “sunk costs” of using old technology (MS Word… I am looking at you!):

– I am used to it, and it works just fine

– I don’t have time to learn something new

– This is too confusing…

Note that this is your brain resisting change. When you evaluate a new tool, honestly consider the question: “if I were a master as this would this help my project and my team?” and try to ignore the “I don’t want change” mind chatter. 

Back to business! 

To get the most out of this tool, you will need a Google Account. It’s free to get one – free as in you pay with your attention and your privacy. If that is fine with you, then let’s proceed. 

Top collaboration features:

1. Multiple Live Editors of the document

This is ideal when you work with your team over a Zoom or Skype call. It allows everyone to open the document on their device and start working on it. The changes will be visible to everyone nearly instantly. No more sharing of Word Documents around! 

Tip: it may be a good idea, for some projects, that each editor uses their own color, so you can know later on what you wrote and what others wrote. (This is just a simple solution to this the advanced way is “version control” explained last)

2. Make suggestions instead of edits!

This is based on (or similar to) the MS Word “Track Changes” feature. You need to change your editing mode to “Suggestions,” and now, all the changes you make will have your name attached to them, and they will be next to the old text (instead of overwriting the old text). This feature allows anyone to chime in when doing brainstorm and review. At the end, the author of the document can review all the suggestions and approve or reject them. This is such a powerful tool because you can instantly see on the side of the document if there are changes that you need to review, and you have the name of the person who suggested the change. On top of this, each change gets a comment section where you can ask for clarifications, or you can explain why your suggestion should be accepted. 

This is, by far, my favorite tool to use when working on a document that requires the team’s input.

3. Comments

This feature is similar to the previous one. But instead of editing the document in “Suggestions” mode, you select a piece of text and make a comment on it. 

This comment will create a discussion box around it. This feature is useful in some cases, but it lacks the quick “accept/reject change” buttons that a suggestion has. So any editing suggestion you make as a comment has to be manually typed into the document later. 

Comments are great to give feedback on the text regarding legibility or clarity because you are not suggesting a change, you just need the author to make some clarifications. 

4. Assigning Tasks

This tool does not replace a proper project management tool (like Asana or Trello) but, for small teams, it can work wonders! Using the comments or suggestion features, when the discussion box is open, you can notify someone (prefix their name with @), or you can assign that item to someone (prefix their name with +). 

The beauty of this is that they get an email notification, so they will know their input is required. And if you have assigned the item to someone, in their google drive view, next to the document name, they will see a number of pending issues that they need to resolve. 

I hope it is obvious how this can be used to keep track of what needs to be done in a small project, so you don’t have tasks being forgotten or now knowing who is supposed to work on them. 

5. Version History

This is the least used feature, but one of the most powerful. I am a big fan of backups. It allows me to move quickly and to make mistakes, knowing that I have a solid safety net. If I screw up, I can restore the old version, and everything is good again! 

For large documents and documents that need to go through many revisions, sometimes it is helpful to see a “history” of how the document grew, what was changed, why, and by whom. Google Docs allows you to do that out of the box because the document has in it a history of the changes. This is tracked automatically, you don’t need to do anything. 

You can, however, at some point, label one of the versions as, say, “Final Draft” or “Version 1 – Published” and later one “Version 1.1” and so on. These labels that you create make it easier for you and the team when you go back to look at the timeline to make sense of what are the important edit points. 

In software development, this tool is used a lot, and I know how powerful it is. If you are new to this “version control” thing, you may not see the power of it right away, but give it a go in a big project, and you’ll not regret it. You will no longer be afraid you make a mistake, or that someone in the team got in and accidentally destroyed the document with large copy/paste operation. You can always “go back in time,” to when things were in good shape! And when you are no longer concerned with making mistakes, you can allow your creativity to shine!

In conclusion 

I’ve stormed through these features. If there is one in particular that you like, look for YouTube tutorials about it and put it to good use! 

Go create something amazing!

Conversions versus Beauty

As a designer, or even as a client, you are thinking of starting a new project, and you need to begin your UI design. 

And you’re thinking: it has to be modern, it has to be beautiful, it has to be exciting, it has to evoke these feelings and then from the infinite number of possibilities you need to choose something that will be your design. 

This can be daunting, and it may not actually serve you. And I confess I had made this mistake in the past a lot! I would learn new fancy ways to do something, and then I would use it everywhere because, drum rolls, I knew how! That is an excellent way to learn and practice your craft, but it is a terrible way to think about design. 

When I began working in projects that had a real business behind them, it became evident that once the design was done, other questions would come to the fore:

– how many visitors do we have

– out of those, how many became leads (subscribers)?

– out of those, how many purchased a product? 

– and out of those, how many become huge fans or joined the mastermind groups? 

These questions have something in common. They are not about esthetics, they are about numbers, and specifically about conversion rates: how much of X turned into Y? 

Now I start all the projects with these questions before even considering the design!

Who is supposed to use this website, and what for? And once I have an answer, what kind of action do I want my audience to take when they interact with my site? How will I measure that? And how do I maximize that? 

The answers to these questions will limit my design choices. And that is a good thing because fewer choices increase the chance of making the “right choice!”. If you go too crazy with your design, users will not be able to relate to it. If you are the same, then why should a client choose you? You need to find the sweet spot! Something that the potential customers can relate to, but that is also customized to serve their needs. 

This means you will need to choose specific fonts, certain colors, and image themes that will be dictated by your target audience and not by what you think “is beautiful.” 

If you are a designer and you need to make a choice, ask yourself: will this bring me closer to my conversion goals or not (pretty comes second).

And if you are a client, be very careful when you ask for a change because your brother does not like the colors, or you don’t like green. If you build something to serve an audience, then their preferences matter over yours. 

Of course, every decision you make can be wrong. You can make informed assumptions about your audience, read the studies about how color influences people and how the font face can make you look serious or playful, but you can still be wrong and not meet the conversion rates you were aiming for. This does not mean you have failed, it means you need to adapt.

An excellent way to adapt is to use A/B testing. I am still studying this concept myself, and it looks like a powerful way to reach “DDD” which is Data-Driven Design, versus “Beauty Driven Design” (which is a polite way to say “Guess Driven Design”). 

My challenge with A/B testing so far is that you need to have a broad test audience to be able to safely conclude that one variant of the test is definitely better than the other and by how much. If you’re into statistics, you’ll love this, and you can do the math yourself! If you are not, choose your testing tool wisely to avoid running meaningless tests with results that are not actually relevant. 

A case study is the website PenguinMagic. When I first looked at it, my design eye judged it as ugly and imaged someone lost their money paying for that. But I have learned that this “ugly design” converts for the people it is addressed to. Believe it or not, this is a multi-million dollar business. They made the clear choice of conversions over beauty!

How about your web project? Do you have goals for it? Are they conversion goals or “being pretty” goals? 

And finally, if you can recommend a useful A/B testing resource, I’d love to read more about it. 

The Importance of Architecture and following best practices

As a young programmer, I was eager to dive in and get my fingers dirty as quickly as possible—no need for a plan or a direction. I knew I could figure it out as I went.

Fast forward some years, add higher project complexity over a more extended period, and the lesson became clear: sometimes if you want to run for long, you need to run slower and have a plan!

Figuring it out as I went worked fine for one-day projects or one-week prototypes. But when bigger projects came my way, I got to a point where I could not remember anymore what my initial think was, where was I headed and why, and how to present my idea to new members on the team.

Although nobody likes to write documentation, I began to make a habit out of it, and I knew it would come a day when I will thank myself! By now that day has happened many times 🙂

What would I tell my younger self?

Writing docs and making plans is not sexy, and in general, your clients do not care for them. They need working software, not documentation. But if the project is longer than six months, a few problems will begin to crop up:

– you forget why you took the decisions you made with the initial design

– if you will need to refactor your code, and if it is not well documented (and if it lacks automated testing) the job of refactoring will take a long time, and you run a high risk of breaking functionality

– by using best practices, you future proof your code – you make sure that you at least don’t make the same mistakes that others made before you. You will make new ones, for sure, but your overall code will be much more stable, easier to maintain, and upgrade.

In conclusion, there is a time to be quick and messy (when you are prototyping), but then you need to slow down and think things through.

Innovation is messy

A hard lesson I have learned recently. 

I like to be right. I like to be efficient. I like to do things the correct way the first time around. I would like to believe that my experience would allow me to do so. 

But some projects present an interesting problem. To understand the problem, let’s imagine we are the architects of a tall and spectacular building. 

We know how the building is supposed to look. We know what purpose it will serve and who will use it. With this information, we can start making our plans starting from the ground up. We design a solid foundation, and then we layer on top of that floor after floor until we finish. 

However, this is not innovation. Is following a well-established workflow where there are little to no unknowns. We can make good decisions about what materials to use where and a reasonable estimate about when the job will be done. We don’t expect many surprises along the way. 

But what if we have this idea to use a new material, and design this building to serve some innovative purpose that no one has done before. Now there is no way to lay down a solid foundation because you cannot answer the question: “solid for what?”. 

You may discover halfway through that most design decisions do not help you achieve your vision due to some unknown limitation that was invisible right until you got to this point. So you have to dynamite the whole thing, learn your lessons and try again. 

Large, innovative software projects are like that. The architecture you started with may have looked great in the beginning but ends up feeling very limiting when you suddenly realize you need to make a dramatic shift in your project, and your “foundation” does not allow for it. Tearing down a software project is free, compared to dynamiting a building, but you still won’t get your money back from all the work that you cannot use anymore. 

But not all is lost. Because in this process of trying and failing, you learn and you grow into your idea. You stumble into the things you didn’t know that you didn’t know. And drip by drip, you make the unknown, knowable. 

This “failing often” is a challenge for me to accept and work with because it feels wasteful. In hindsight, “I could have done better!”. But thinking like that is a trap, and it suffocates the very creativity required for innovation. You need to be ok with failing often. 

Now that we can agree that innovation is messy and it feels wasteful, what can we do about it? 

1. Don’t start with a big spectacular thing. Instead, try to come up with an MVP (minimum viable product) that you can build on (or next to) in the future. 

2. Budget for the messiness and the learning process. Make sure you have enough money to make the mistakes required to get the learning experience you need to bring your idea to life.

3. Aim for many small mistakes, so you don’t make one massive “end of game” mistake. This idea expands on (1) above. Move fast, but take small steps. This approach will make it easier to backtrack and change direction. Significant commitments are giant leaps forward that give you less flexibility to turn around. 

4. Don’t worry about optimization and edge cases in the beginning. If you do, you may end up doing tedious and lengthy work on a feature that may not even make it into the final product.

5. Try again tomorrow. Some days it may feel like you are getting nowhere, and this is all doomed to fail. That is normal. Take a break, go back to the original vision that got you excited and try again tomorrow. 

6. Be patient. You are playing the long game.

7. Once you have your MVP, you can start again and “do it right” this time. It will no longer be innovation because you have learned your lessons. Now is the time for the polished, optimized, and secured product. 

How do you deal with innovation in your projects?

The self-diagnosed client

The self-diagnosed client is the person who comes to you with a problem, a solution, and they only need you to implement that solution for them!

Does that seem right to you?

Consider the following scenario. A person goes to the doctor; this person knows the problem; knows the treatment and only asks the doctor for the medicine they want. In most places, it would be a case of mal praxis for the doctor to accept the self-diagnosis.

At the very least, the doctor would ask questions to confirm what the real problem is and confirm the diagnosis, right?

When it comes to online businesses, the issue is not that clear cut, and it depends on what you are selling.

If what you are offering is creative, custom made solutions, then a self-diagnosed client is a disaster waiting to happen. You cannot know if the two of you are a good fit if you have not followed your own diagnosis process that will enable to serve the client best. The client doesn’t know what they don’t know… they have a blind spot. If they knew everything, they would not come to you for a custom made solution. So it is your job to at least confirm the problem and what they think the best solution might be :).

In case of a more standardized offer, then it is indeed up to the client to make up their mind if your offer is a good fit for what they want to do. You can, of course, help make up their mind with excellent communication about your product or service.

To Backup or not to Backup

Some years ago I had the opportunity to work alongside a veteran software developer. That was a treat for me and also a way to learn big lessons fast.

I remember being overconfident in my abilities, fresh out of school, and making silly mistakes when all that knowledge had to be put into practice.

I wanted to be quick, and agile, and free! I wanted to get in, fix the problem and move on!

But there was an incident that taught me a valuable lesson.

The server we were managing got hacked and crashed.

Working alongside the Veteran we managed to identify the security vulnerability, fix it and then restore the website within 6 hours. This was a big and popular forum. 6 hours recovery time was much shorter than the couple of days that this usually takes.

Shortly after restoring access, I heard from one of the members saying: “The way you recovered from this and the speed at which you did it is nothing short of impressive. In my career, I have worked for big software companies and none of them have in place such a good recovery plan.”

I could not take much credit for that, so I decided to pay attention to “the Old Veteran” because it was clear now he knew was he was doing :).

The Importance of Backups

We were able to bounce back so quickly because we had backups. Now only that, but we had versioned backups. Meaning we could go “back in time” to before the problem, see what changed and fix it. And then restore almost all of the user data, with minimal loss. Without versioned backups, this process would have been long and tedious and I do not know if we would have been able to spot the point of entry.

This is a happy ending story and here is what I have learned:

1. You always do backups – even if you think you don’t need them.

2. You test your backups – an untested backup is no backup. I have a story here where a client was paying their hosting company for a remote backup system and when the time came to use it, the backups were corrupted and so not usable.

3. You never delete things – you rename them and then archive them – this way you can always retrace your steps back to something that was working

4. When writing software you always, always use source control – which is basically a system that does smart backups of your work that allow you to “go back in time” and fix problems.

A beginner’s mistake- “I am too good for Backups”

As I have said, fresh out of school, I had bright ideas and I wanted to move very fast, but I did not ever have to deliver work that was used by real people, in a real situation, facing potential attacks from real online threats.

When you are prototyping and testing out an idea, it is OK to be quick, because if the idea is bad or not useful, you need to find out fast. But once you have something that you want to build out for the long term, then you need to switch gears and sacrifice reaction speed for being more organized.

I confess that this did not make sense to me for a long time. But as I worked in bigger and bigger projects it became obvious how the “slow work” of thinking of a structure to organize your code, setting up source control and doing backups was actually the fast lane. Why? Because it reduces risk and allows you to easily maintain the project as you move forward.

The opposite of this is working at neck-breaking speed, not “wasting time” with backups or source control, in order to put something on the market quickly. All the projects that I managed or I was a part of, that did not put in the time to be organized, eventually ground to a halt and had to be abandoned or rewritten.

I have done this mistake enough times to learn my lesson: for quality and sustainable work always do backups and use source control.

Client’s point of view – Do backups make business sense?

It is now obvious for me that backups are not just a good idea. But why should you care about them?

It depends on how well you can manage risk and how important is your data and your customers’ data to you and your business.

If you can afford to lose it all, then you don’t need backups.

If you can afford the downtime of having to rebuild your application from scratch, then you don’t need backups.

But in my opinion, good backups are a cost-effective way to mitigate the security and data loss risks associated with running an online business.

Do you have a backup policy in place? And if you do, have you tested your backups lately to make sure that you will find in there what you expect to find?