Freezing Code

Using CloudQuery for Marketing

2024-03-20T00:00:00Z

I like to measure things. I like to know when what we do actually makes an impact and when we need to improve. At CloudQuery, we used to churn out blog posts and videos, and at one point, I started wondering if they were actually worth the time spent.

Considering we posted on a number of social media, on our Discord server, and we also sent emails, we faced the challenge of bringing all the data together in one place. We had questions about who we were reaching, how our audience was growing, how our posts were performing, and what content really clicked.

Luckily, we knew a company that made a tool just for us: our own! Apart from solving a real problem for ourselves, I was excited about the opportunity of “eating our own dog food” and learning about the challenges some of our customers may face.

Making It Work

First, we mapped out the user journey: what do we want people visiting our website to do? How do they get there? Where are the points where we can measure the number of people getting through?

We reviewed the tools we were using. For website analytics, we used Simple Analytics. We had Typeform for surveys and signups, Discord, Twitter, LinkedIn, and YouTube for socials. We also used Hubspot as a CRM. We decided the best way to measure the campaign's performance across the social media was to use Bitly links with UTM tags.

The setup with CloudQuery was pretty straightforward: we now have a few containers running CloudQuery with a cron schedule. Plugins such as Typeform, Bitly, HubSpot, and Simple Analytics are used to sync data from the individual services to a single Postgres database. Another container hosts a Metabase dashboard to help us dig into audience engagement and post performance. We are looking at how our posts to social media are doing from the clicks perspective, how the individual content from emails and blog posts is driving engagement, and how it all translates to website visits and signups.

What We Found Out

First, we ran the syncs too often with Bitly and almost ran out of our monthly API quota 😅.

We had to develop a new plugin for Bitly using our Python SDK. It was fairly straightforward, although we found out a few things we could improve internally. These will help more developers coming to our platform to develop new plugins.

We learned and also confirmed what we knew about social networks and devised a new strategy for one of them.

What's Next

Looking forward, we are not stopping here. Our plan is to include YouTube in our data mix. While Youtube has its own analytics dashboards, they do not offer as much detail as the actual API does. We also think the power is in combining the data with the other data we already have.

Get inspired by our selection of plugins for Sales and Marketing on our Hub.

Are you interested in learning more? Or have your own story about your data integration journey to share? We’d love to get in touch!
Find us on Discord, Twitter, LinkedIn, or just book a meeting directly.

New project - Recipe Book

2023-05-17T00:00:00Z

I have a new side project: A recipe book.

Since the pandemic started, we kind of changed our habits of going to a store every week for a load of food for the upcoming week. We thought we could reduce the time spent among other (infectious) people by shopping only once a month. Sure, you still need some fresh produce, such as vegetables and fruits, every week, but that limits the store visit to ten minutes.

Since we moved to the north, the need to do a one monthly shopping trip has increased even more. The store with good prices is around 100 km away and it takes an hour to get there (if the weather permits). So every month, I take my small Ford Fiesta, drive to the store, load the car with food and drive back home. It takes half a day but then I have the other weekends free.

This approach to shopping required us to change the way we plan meals. We actually need to sit down and plan what we're going to cook each weekend until the end of the month and make sure we have all the supplies. We were looking for a tool that could store our favorite recipes, include ingredients, and plan meals in a calendar. It should also be free and available on all platforms.

We found one that wasn't free and we almost started using it but then we learned it requires a payment on each platform (PC and Android separately). So as product managers do, I said I could code something like this over a weekend and picked up this new hobby.

This happened couple months ago (ha ha) but now I'm ready to share it with the world. It's ugly, but it works. Also, it's free (for now). And I learned a lot new stuff about React, NextJS, Google authentication, and that I also don't really want to develop mobile apps.

Snowmobile ride

2023-04-29T00:00:00Z

Using a snowmobile, you can get to places that are otherwise impossible to visit.

Google Calendar Event Colorizer

2021-10-12T00:00:00Z

I prefer to see important events (i.e. events with customers) in my calendar with a different color so I notice them in time and get prepared. I used to edit the invitations manually to set the color but I often realized I forgot to do that until it was too late.

Here’s a little script that helps me colorize the events automatically. It sets the predefined color on every calendar event with guests from outside of my company: https://gitlab.com/pilvikala/gcal-event-colorizer/-/blob/main/index.js

How to use it:

Go to https://script.google.com/home
Click ‘New script’
Paste the script from index.js
Read the comments in the top of the index.js file and update the variables to suit your needs.
Save the project and give it a name
Run the project. It will ask you to give the script permissions to access your calendar.
In the triggers tab, add a trigger to run this periodically

The power of no

2019-09-21T00:00:00Z

I am very bad at saying No. It is an issue if you consider the fact I am a product owner, but I really have a hard time saying No to people who want new features or who desperately need some bugs to be fixed. I am a product owner that wants everyone to be happy.

At the company I worked with in the past few months, I was basically the one who said what features we would implement and what bugs we would fix next. We had a long-term strategy I had to comply with, but those tiny details affecting hundreds of users were for me to decide on.

I had requests for changes, new features, and bug fixes coming in all the time. Most of them were from our customer success representatives - the people who were providing support to our end users. They knew what the long-term strategy was and they knew what we were planning to work on in the near future, but they always tried to push “just one more thing” in.

Could I say no? Of course I could, and I actually tried that multiple times, but I was often overruled and my short-term plans became mid-term plans and the long-term strategy became only a vision.

One day when another urgent request for a bigger feature came from one of my favorite customer success managers, I tried a new approach. I laid my cards on the table and told him that these were all the things we were planning in the upcoming months, and most of them were requests coming from him and he had said they had been urgent. I asked him to help me to figure out where his new request should be squeezed in and what were the bug fixes we would postpone due to this new one. The result was amazing: he said his new urgent request could actually wait, the things we had been planning to fix were actually much more important.

That day I learned that the major stakeholders in the company suffered from poor memory. They always focused on what was most important for them at the moment but never looked at what was promised and planned before. Since that day, whenever someone has come to me with a request that seemed to be imperative to get done “right now” I asked them whether it was more important than what we were doing at that moment or what we had planned for the next few weeks. This eventually led to their satisfaction because they could have provided their input on what needed to be changed and they were able to influence how important the change was. It also reminded them what we were planning to do so, and thereby reassured them that we were (still) going the right direction.

And eventually, I was happy too because I no longer needed to say No.

Requirements

2018-02-25T00:00:00Z

I just got a bullet list of high-level requirements for a new tool. The last bullet was

etc…

Estimates

2017-09-01T00:00:00Z

I collected statistics on “how good my team is in estimating”. The result: not good at all.

At the moment, the only estimate we make is whether a story is big and needs splitting. I measure throughput in stories per week.

Wi-Fi Sense is gone

2017-08-24T00:00:00Z

Finally! I wonder what made product managers in Microsoft to think this would be a good idea.

For those who do not know, Wi-Fi Sense is (was) a new feature in Windows 10 that allowed you share your Wi-Fi credentials with your Facebook, Skype, and Outlook contacts.

Now Microsoft said people had not used it so the feature was removed from Windows in the latest Anniversary Update.

I just cannot understand how this idea was not killed shortly after its inception. I mean, there are multiple ways you can validate your ideas - asking your users, potential customers, comparing the feature with the goals you are trying to achieve, and so on. Who were the people who said “yeah, I would LOVE to share my home Wi-Fi password with all of my 155* Facebook friends!”. What could have been the goals Microsoft had this feature would help to reach them? Or was this a result of the lean software development? Did they want to make this bigger so they made a small step to try whether the feature succeeds so they could develop it further?

Can you imagine what the “further” could be? Sounds quite scary to me…

average number of facebook friends as of Jan 2016 according to this page: http://www.telegraph.co.uk/news/science/science-news/12108412/Facebook-users-have-155-friends-but-would-trust-just-four-in-a-crisis.html

Too many options

2017-05-01T00:00:00Z

My recent visit to Subway reminded me again why I prefer to avoid this fast food restaurant. It is not about their subs, or what they put in them. I actually like the combination of tastes, but I hate the process I have to go through to get the actual sub.

At first, it looks so simple. They have a board with pictures of 16 different types of subs, and I can see the price I am going to pay. The lady asks me what I want, and I tell her I want the Italian BMT. Clear and simple. But then…

… I have to choose which type of bread I want. I did not expect it, but it’s actually not difficult to choose the type of bread, is it?

And then she asks me what I want to put in it.

Well, I want THE Italian BMT. I want to replicate the image in the picture. I don’t want to guess what’s in it! So, I calmly explain I want the Italian BMT. She nods, puts some ingredients on the bread, and puts the bread in a grill.

21 seconds later, another lady comes and asks me what I want in my sub. Come on! I want the Italian BMT, and I’m confused because I am not sure what’s not clear on wanting the exact sub that is displayed in the picture above her head. She explains that I can pick anything I want, but I am not really in a mood to pick my ingredients in order to experience the true Italian taste, and there’s a long queue of other people behind me, and they all suddenly look nervous because they have to wait for me to decide what I actually want. Because of this, they will be late for work and the GDP will go down by 20% because I am so slow and cannot guess what’s inside the proper Italian BMT Sub!

I resign, tell her I want tomatoes, leaf salad, and jalapeños, a combination that is NOT Italian at all but I don’t care at this point, I just want to go home, get in bed, and cry and pity myself for bringing down the already-on-its-knees Finnish economy.

She asks me what sauce I want in my sub, but notices the pale color of my face and immediately recommends one to go with it so that I won’t really have to choose here, and my life is getting much better again.

Then I finally pay, sit down in a dark corner, and eat my sub quietly.

…

I am sharing this story because I can see there is a parallel with software. It’s the dark place where we, the people developing software, offload all of our decision making. Instead of deciding a problem for a user, we let the user decide what they want. Not sure how this small thing should behave? Having too many different opinions and each one seems valid? Let’s put it to Application Settings so the users can decide on their own!

Next time, when adding a new user option, remember the Subway story, or visit Subway and experience it on your own, and then get back to review your original user story and its goals to decide what the right option for your customer is to save them the trouble and offer them the right sauce.

PS: Do you know Subway has a help page on how to order a sub? I don’t feel like I should need to read a manual before ordering a sandwich: http://www.subway.fi/en/products/how-to-order-your-sub

Language specifics

2017-03-03T00:00:00Z

You may decide that the only language your software will ever support will be English but that will not save you from the traps of differences between UK and US English. Here’s what I found today when describing an existing UI behavior:

“For example, searching for "yellow” will show projects with traffic light set to amber.“

Now what?

Change the world or do nothing

2016-08-24T00:00:00Z

I have just read an article about Washington, DC’s useless streetcar service and there was one very interesting part that caught my eye:

…Washington’s planners seem to have been so fixated on the low price tag that they have not asked themselves the central question that should guide any transit plan: will it actually be useful in moving people?

(source: http://www.economist.com/blogs/gulliver/2016/02/streetcar-mire)

You could say this is a typical government project. But isn’t this something that is happening in your company too? How often do you ask yourself how this user story is going to be useful to the users when it is implemented?

When implementing a new feature, there is usually a user in the beginning that says what she needs in your software (let’s call her Susan). Susan usually says things like “I need this apple to be blue”. Right at this point, you have two options:

a) Go and tell the team to paint the apple with a blue color.
b) Ask why.

I know many people in many companies that paint apples blue. The streetcar service in Washington DC is an apple painted blue. I think this is happening because people tend to not oppose to someone who is offering to pay money for something to be done. It might be because asking “why” may (and often does) lead to “I don’t know, you’re right this is stupid, let’s cancel this project” type of answer effectively meaning no money for the company that asked. And also, the “why” may seem as direct “no” which makes people angry (your boss being one of them).

But if you do not ask why you will never find out what Susan actually needs. When you give her the blue apple in the end, she will find out it is not what she had needed and while she still may pay you for the project, she will not ask you to run another one for her.

For option B, you can start with the simple “How is this going to change what you are doing now?” The change is important. Most of the time, Susan is just trying to make her own life easier by introducing a change in it. A change, that will save her time, money, or a change that will give her a special benefit. You know, Susan might actually be the Evil Queen and what she really needs is this:

(source: http://disney.wikia.com/wiki/File:Snow-white-disneyscreencaps.com-7307.jpg)

Or maybe she just needs to move Snow White out of the country!

Asking the right questions will help you finding out what Susan’s actual goals are and only after that you can help her achieving them. Jeff Patton, the author of the User Story Mapping book calls it “changing the world for the user”:

“Every great idea you turn into a product solution changes the world in some small, or not-so-small, way for the people who use it. In fact, if it doesn’t, you’ve failed.
(Jeff Patton, User Story Mapping, loc. 383).

I say, change the world, or do nothing. There’s no other option.

Fifty quick ideas...

2016-07-04T00:00:00Z

Fifty Quick Ideas To Improve Your User Stories is a really great book. What makes it even better is the set of hint cars (bought separately) you can carry with you to your grooming meetings.

Scrum is not a sacred cow

2016-05-01T00:00:00Z

What benefits do you see in having sprints?

This was the question I asked one of my teams couple weeks ago. A half an hour long discussion rendered just one answer: “None”. And so we decided to try working on our project without the deadlines set by the timebox of the sprint.

When I told others about this, I was told the idea was stupid. People need deadlines, I heard. Without the deadlines, they would just hang around and did nothing and the overall morale of the team would collapse.

We tried it anyway - we cancelled the sprints while keeping the other artifacts of scrum like daily standups, bi-weekly retrospectives, or bi-weekly demos for stakeholders. After a while, I talked with the team to gather feedback on this change. Here it is:

Pros:

The obvious one is sprint planning - or the lack of it. This saves some amount of time. The standard backlog refinement meetings (backlog grooming) are still happening and we talk about the details of the stories there. After the refinement, they are usually ready to be taken by anyone in the team and implemented (according to priorities).
Before, we often had discussions about accepting stories similar to this one:
Me: “I like it, but there’s one little refinement I would like you to do before accepting this story”.
Team member: “It’s not in the acceptance criteria and we can’t make it in this sprint. Can you open a new story and put it in the next sprint?”
Now we continue to work on the story until both I and the team are satisfied. We do small tweaks, sometimes even vet the UI with the designers, and nobody is complaining about something missing in the acceptance criteria.
The above actually leads to a better quality. There is no pressure at the end of the sprint to finish all the commitment that was previously based on estimates. The work is done when it is done. This also removes all the long conversation about what would be the way to finish something by the deadline.
The above also killed the dead time just before the end of the sprint. Parkinson’s law has no effect here to fill in the remaining time with more work - we just continue working on what is in our backlog.
Team uses common sense more - I am not sure what the actual cause is here. But it appears that the removal of the pressure on the deadline removed the need to meet just the specific acceptance criteria. People think more about the actual purpose of the story and even if I omit something, they come back and tell me what I wrote does not make sense.
The team feels more relaxed (but the average velocity did not drop down).

Cons:

I have to pay more attention to the size of the stories. They need to be small enough to fit into a week so I can keep tracking progress, and I actually need couple stories to get implemented during the week. This means a bit more work and a bit more thinking for me.
Some people feel that the missing deadlines make them less productive. However, there is currently no evidence for this, it is just a feeling.
Some people feel we have been just lucky that it has worked.
There is a concern that in a long term, this may feel like a marathon with no specific milestone. We are trying to mitigate this by having regular demos to stakeholders, betas, and we will have to release a product eventually.

To me, being agile is about the ability to improve on what you are doing and adapt your process so it makes you more productive. Using scrum retrospectives to find out sprints are causing friction and therefore they need to be cancelled is perfectly legal - we removed the major obstacle to our productivity.

The point of this post is not a suggestion you should cancel sprints. It may not even work for you. As the title says, scrum is not a sacred cow. Stop following it blindly, question it, and find and remove the part that is causing the biggest friction, even if it undermines the whole process.