Forem: Tability

How to build a Pragmalith

Sten — Fri, 10 Apr 2020 06:29:25 +0000

This is a long overdue post, and I'm going to expedite it because otherwise I'll never post it. There's a heated debate going on right now about microservices vs. monoliths and I'm here to introduce you my answer.

BEHOLD. THE PRAGMALITH.

What is a Pragmalith?

A Pragmalith is boring. It's a way to build your app that embraces your ability to fuck up and tries to minimize the impact of your mistakes. It also recognizes that discipline is hard, so why not force good practices on us?

The rules of the Pragmalith

1. Choose the familiar rather than the exciting

Pick the edge cases and bugs that you know rather than having to discover new ones. Treat innovation like a rare and precious gem. Read Choose Boring Technology and pass it around.

2. Don't trust yourself

Document things. Write comments. Write tests. Don't SQL your prod database. Put safeguards in place to save you from the day you'll be too tired to care about discipline.

3. Don't be clever

Do things the boring way. Clever code won't save you CPU cycles but it will kill many brain cells — including yours when you'll come back to it after a year.

(It may also cause hair losses via forced pull action).

4. Split your frontend from your backend

Backends and frontend have different lifecycles. Keep them separate to minize risks. It will also prevent some spaghetti shortcuts where build backend logic in your views.

This here is the only rule where I'm calling for something specific. And this is coming from my experience. I worked as a dev and as a product manager and I'm absolutely convinced that separating the frontend cycle from the backend cycle works best for everyone (I can expand more on this if you really want to — just ask in the comments).

5. The default answer to creating a new service should be "No"

If you think you need a new microservice then you probably don't need it. New services or repositories should be painkillers, not vitamins.

E👏v👏e👏r👏y👏 new service will add a new set of 👏pro👏blems. Testing, deploying, backing up, testing the backups... Adding more services is expensive and brutal. And it should be weighed against a real pain felt today (slow release cycles, devs stepping on each other, etc...)

Architecture vs. practices

A Pragmalith is not just about how you structure your services. It's about having a certain mindset where you try to minimize headaches and avoid unnecessary complexity.

Do the things you have to, not the things you want to.

Why not a Monolith?

Monoliths have their own problems at scale and you'll need to break them up at some point. But really, it's about being pragmatic and do things that work for you.

I don't trust myself to have the discipline to avoid shortcuts in the code. That's why our backend is a REST API in a separate codebase: it has clear inputs and outputs, and you can't cheat in the views. The separation of concerns is forced on us.

What's our Pragmalith at Tability?

Rails 5 API backend with Postgres
React* for the web app frontend
React Native* for the mobile app
Gatsby for the website
A Rails microservice for the Jira Connect App

* Items with a star mean an innovation token was used at the time

React was a new framework at the time, thus being an expensive innovation token to use. BUT, it was going to remove a lot of pain for our small team. We could re-use a lot of the web app code for the mobile app, and once I got the hand of React it became quite easy to approach Gatsby.

But all the other stuff is boring. I really want to try Elixir and Phoenix, to learn more about Kubes, to explore all that AWS has to offer. But it would kill us.

We'd have an exciting tech but a boring product.

The Pragmalith hates fights

A Pragmalith is something that works for you and your org. The threshold of what's boring moves with the competencies and experience of the team.

I'm out ✌️

How we replaced (part of) Intercom with 100* lines of code

Sten — Tue, 27 Aug 2019 12:37:39 +0000

Edit: less clickbaity title

(*ok, it was 105 lines)

We started to use Intercom the classic way: we wanted a simple way for people to reach out to us. Whether they were curious visitors or existing users, Intercom gave us a great way to interact with folks and have rapid feedback.

So, to be clear, we love Intercom ❤️, and they're an inspiration in many aspects.

But we started to see issues with feature announcements:

Users would have a hard time clearing messages.
New posts would pop up in odd situations.
It wasn't possible to find old announcements if you missed it.

I'm sure that a lot of it was due to a poor configuration on our end. But even if we got better at posting, it still would not solve the last issue.

Replacing Intercom with another solution has been a real "scaling small" exercise. We wanted to be able to keep moving fast and letting users know about improvements, but we also had to manage costs — we could not justify spending more than a couple of days on an alternative.

Looking for a better solution

I've been burned several times jumping straight into code, and I learned the hard way that you should step on the brakes first if you want to cross a wide road.

We have a simple way to evaluate options when we're about to build something significant. First, we look at the core capabilities:

Customers can learn about new features.
Customers can find old announcements.

Then we list some constraints:

Less intrusive
Cheap implementation costs
Low management overhead

These 2 lists are enough to start outlining options. It's crucial to add the status quo as the first option because you need to make sure that you're improving things. If you just compare a set of new solutions you risk picking an approach that might degrade the current experience.

So, here's what the first set of options looked like:

Keep using Intercom (status quo)
Hardcode announcements
Build our own announcement feature

I put them in a table and made a quick comparison to see if option 2 or 3 would be satisfying.

None of the proposed solutions were satisfying. Hardcoding posts would be super annoying to manage, and building a full service was way too expensive.

We kept looking around for inspiration, and, not without a bit of irony, the answer came from Intercom itself.

The lightbulb moment💡: using what we had

The goal was to let customers know about new features — nothing more. But we were so focused on the current experience (everything in-app) that we did not look for a different approach.

Well, Intercom has a small bell icon in their navbar for feature announcements. It gets a red dot when there are new things to read about, and clicking on the bell takes you to their blog. No intrusive popup, no messages to dismiss.

That was perfect.

All our feature posts were already on our blog, and this is where customers could also find old posts. So we just had to send them there to read about what we've done to improve Tability.

No backend required to manage posts. No need to create a fancy listing in the UI. We just needed a way to show that new blog posts had been posted.

That was done simply by using localStorage to capture the last time they clicked on the link to the blog. Sure, the notification would pop up again if you switched browser for the same account, but that's still an edge case right now (but we'll fix that later).

105 lines of code later

We're pretty happy with the result and we will iterate on the implementation to improve it:

We still have to store the timestamp of the last blog update somewhere in on frontend (we deploy multiple times a day so still manageable).
Having the notification popping up again in different devices will end up being annoying when we launch our mobile app.

It's not what we originally had in mind, but it does the right job: reducing noise while letting users learn about improvements.

The lesson learned? Focusing on what the customer needs to do, rather than the experience you want to ship lets you be more creative.

(Also, 105 lines could have been shorter, but Redux...)

The 4 stages of goal-tracking (aka don't jump into OKRs)

Sten — Fri, 22 Mar 2019 05:05:09 +0000

This is the second post in our series about pragmatic goal-tracking. While this is not diving into dev practices it's something that I believe is important to empower Product teams. By being more outcome-driven you can reduce micro-management and let the team own more of the future.

You can check the previous post introducing the business case for setting and tracking goals.

Staying productive as you grow is a common challenge for teams. Agile practices help a lot to make sure that your projects are delivered faster, but they don't guarantee that your team is working on the right initiatives. This is why goal-setting, and the Objective and Key Results (OKRs) framework in particular, are rapidly gaining in popularity - they provide an easy way to create a shared understanding of what matters for the business, and what the top priorities are.

However, it's often daunting to go from nothing to setting multi-level OKRs that are tracked religiously. Change management is hard, and there are multiple stages to pass in order to grow your outcome-driven muscle.

Stage 1: No shared goals

This is where you start, and while it might sound silly it's an extremely common place to be.

When you're early stage it's hard to have a clearly defined view of where you want to be in 3, 6, 12 months. You're still figuring things out talking to as many users as possible and trying to get a sense of what the market wants.

You might have a target for revenues and users but it's not broken down much further in metrics that each member of the team can relate to.

What are 5 signs that you're in stage 1?

There are no goals beyond revenue and customer growth targets.
There are no monthly and quarterly review of progress and impact.
The roadmap is reactive, new projects are decided when the current ones are finished.
Micro-management is needed to make progress. The team doesn't have enough understanding of the path forward to make their own decisions.
The team feels disengaged from the product - people are checking-in to do the work decided by leadership.

Stage 2: We want goals

Even if you do not plan for stage 2 it's something that you'll get to eventually as your team grows. Past a certain size, it's not possible to keep having in-person discussions with everyone, and it's hard to keep up with the number of open questions about the future. You have more people moving together, and you need good ways to make sure they're going in the same direction.

You're just starting to think actively about your North Star and most of your effort will go into changing the culture to build more trust and become more data-driven.

What are 5 signs that you are in stage 2?

You have some metrics beyond your sales and customer targets but they're mostly defined by leadership.
You're covering key performance indicators (KPIs) like monthly active users (MAUs), conversion rates, customer acquisition costs (CAC), but you do not have goals that are driving improvements in specific aspects of your products.
You follow the evolution of your KPIs but have not set targets for them yet.
Progress is generally reviewed on a quarterly basis.
The team has a shared understanding of the vitals of the business, but not everyone feels like they can have an impact.

Stage 3: We set goals

Okay, now we're getting to the stage where things start to scale in an exciting way. Stage 3 companies have teams running their own workshops to define how they'll measure success. There's a clear vision coming from the top that you can look up to understand how you can contribute to success.

There are still some hiccups when it comes to tracking goals and defining realistic targets but people can now work autonomously and report on outcomes to leadership.

5 signs you're at stage 3:

You have a few people championing the concepts of SMART goals and OKRs.
Leadership creates the vision but teams can define their own goals.
Targets are set but there are some big misses due to goals being too ambitious.
Goals are set before each quarter and written down in a shared doc or spreadsheet
But, updates are sometimes missed, and you do not keep the progress history.

Stage 4: we track goal

At stage 4, your company is fully driven by outcome. Every team knows what their focus should be and they are able to self-evaluate to make hard calls on projects that are late or not delivering the impact expected.

This is when your company produces unexpected results as people are able to come up with innovative solutions to achieve a particular outcome. It's also when you can see a high engagement from the team as they become accountable for their own decisions.

5 signs you're at stage 4:

Everyone is familiar with the concepts of KPIs, SMART goals and OKRs.
Teams are able to design a set of goals to improve significantly a particular theme or aspect of their product ( expand customers, knowing our users, ecosystem integrations).
Leadership can focus on longer-term goals (where they want to be in 2-3 years) and let teams define the right outcomes for each quarter.
Progress is shared and monitored on a regular basis (weekly for quarterly goals, monthly for yearly plans).
Historical data is kept and you can go back in time to understand how you got to where you are today.

Moving up the ladder

There are a few more posts outlining how to move from 1 stage to another but I'm mindful of dev.to being a tech community. I'd be keen to share the rest of the series if the crowd is happy (and tech posts will be coming back soon!)

This post was originally published on our blog.

Be like a remote team: empower your team to scale productivity

Sten — Thu, 07 Mar 2019 02:25:11 +0000

This article is part of a series about pragmatic goal-tracking that we're publishing on our blog.

One advantage that we don't talk about often enough about remote teams is that they're forced to ditch micro-management early on and adopt collaboration practices that help them scale execution - you can't rely on verbal checks to get work done across multiple timezones. You need to build trust and get a shared understanding of where you are now, and where you want to go.

At Tability we're small, and remote. And by remote, I mean several layers of timezones between us. I live in Sydney, and Bryan is in Portland. Same love for coffee, different temperatures.

This situation gives us a few advantages:

Great coverage of our customers.
Flexible hours and minimum commute (I work from a co-working space, Bryan works from home).
Long, uninterrupted, blocks of work.

But, being remote also forced us to grow up faster and fix some collaboration issues that you'd generally associate with bigger companies.

The big collaboration problems of small distributed teams

Whether it's on Twitter or in the press, it seems that 2019 is going to be the year of remote teams. And it's not just for startups! Larger organizations are also becoming more and more open to having employees working outside of their headquarters. More than a fad, this is now a convincing perk to attract and retain the best talent in tech.

There's a problem though. The cost of coordination for remote teams is an order of magnitude higher than for people sitting in the same office. A co-located team should be investing the same amount in collaboration, but they can usually do away with it much longer than distributed teams.

Everyone is in the office at the same time. You can talk to the entire team at once by raising your voice.
Impromptu meetings can be organized on the spot.
You can get questions answered right away. Just turn around to your neighbor.

This proximity and availability make it easy to rely on over the shoulder checks (are you done?), rapid interruptions (hey can you check this?) and just-in-time requirements (oh that's not how it's supposed to work...). The alternative is to spend more time up front to explain the problem we need to tackle, outline the expected benefits, define how we'll measure success, and finally prepare the work that needs to be done.

The second approach will yield better results, but the upfront costs are often scary for teams that are already under pressure. So we push back until it becomes apparent that we need to change the way we work to scale.

(Un)fortunately for remote teams, your colleagues are sitting far from you. So you have no choice but to invest in practices that will help everyone on the team to work autonomously while going in the same direction. It's the same type of problem that large organizations are facing when a vision has to be shared by teams that can't meet in person. How can you empower people to move fast in the same direction with low friction?

3 simple steps to switch to an outcome-driven culture and scale execution

The best way to help your organization move faster is by giving everyone the means to understand the impact they can have to take the business where it should be. Instead of giving people projects, you give them goals - they will decide themselves what projects are more suited to deliver the expected outcome.

But turning your culture around can take time and there are a few things to put in place.

Step 1: write everything down, starting with the vision

"If I had more time, I would have written a shorter letter." - Blaise Pascal

It takes efforts to extract one's thoughts and put them down shortly and concisely. And it's not enough to write a few bullet points in a doc. You will need to make sure that everyone has the same understanding of the content, and that all potential questions and doubts have been addressed.

This is going to set the tone for the future - every goal, every initiative that is proposed should relate to that initial vision.

Once that is done you should keep the practice of writing things down, starting by answering a few questions:

What are we doing?
Why do we want it?
Who is it for?
How will we know it works?

You'll note that there's no when in here, and that's because before deciding if something should be done now or never, you should first have a good understanding of its value. Then, you can move on to evaluating the cost, and only after that will you have enough information to see if it is a good fit for your vision compared to other initiatives that you might have on your list.

Step 2: start measuring success

The second step is to make sure that you have the right tools to know if your projects are successful. It's not enough to look at sales and signups. You need to be able to drill down further to have a deeper understanding of how improvements are affecting the performance of your product.

If you want your team to be able to work better autonomously, you need to provide them with ways to self-evaluate and judge if they are making the right decisions. Do you have tools to:

Track events in your product?
Analyze your conversion funnels?
Get you Net Promoter Score (NPS)?
Understand retention, churn?
Know where leads are coming from?
Track your Monthly Recurring Revenues (MRR), Monthly Active Users (MAUs), Customer Acquisition Cost (CAC)?

This list is not exhaustive and it will vary a lot depending on your product, but that's a good place to start. You absolutely need to be able to give more than revenue targets to your team if you want them to make good decisions.

Step 3: Rely on goals rather than projects

My coding background has trained me to focus on delivering features. I got really good at this, being able to do quick trades in implementation to ship a new improvement in time.

A lot of businesses are organized that way. We define projects and train people to be flexible and find solutions to make sure that deadlines are met. It's very effective, but it puts too much emphasis on outputs (get the project done) and not enough on outcomes (get the expected results). It might look like a subtle difference but you're teaching your organization to innovate on delivering solutions, rather than finding the right problems to solve.

This is why, once you know who to measure success, the final step is to switch to being more driven by outcomes. There are different ways to get there but the path we will explore in future posts will look like this:

Start by finding the one metric that matter (OMTM) for your business
Use the SMART template to define underlying goals
Adopt OKRs to structure your goals and get bottom-up initiatives.

That's it for the introduction. Feel free to go subscribe to our newsletter, and you can also find me on Twitter.

A simple goal framework to collaborate remotely

Sten — Thu, 24 Jan 2019 22:40:31 +0000

Last week I stumbled upon the following question on IndieHackers: "Is it possible to have a startup with the co-founders living in different countries?". We're in that exact situation at Tability with one founder (Bryan) in Portland, and the other one (me) in Sydney.

I shared a few tips on that post that I want to expand on here.

Remote problems are large teams problems

Bryan and I both worked at Atlassian before starting Tability, so we have a few years of experience working in large-ish companies (YMMV). What surprised me when we started working as a remote duo is that a lot of the issues we faced were quite similar to the problems I ran into while I was a Product Manager in a team of 20, working with a dozen of other groups across the world:

You can't rely on over-the-shoulder communication to clarify things.
You need to build an environment allowing people to be autonomous.
You need to find ways to keep everyone informed and engaged.

You might object that this is true for all organizations, but you don't really feel the pain if you're a team of 5 all sitting in the same room. At that stage, it's still easy to keep everyone on the same page by standing up and talking out loud, and you're small enough that you can keep track of what each person is doing. But, add a couple more people to the team, and communication will start to break down. There's too much going on, and it becomes harder to identify the signal from the noise.

There's another way to experience that pain, even if you stay small.

Make your team remote-first. Just like we are.

Timezones and distance will produce the same communication issues that you'd have with a larger co-located team. TL;DR; we had to figure out pretty early on how to make sure we would be rowing our boat in the same direction.

Purpose > Focus > Measures (PFM)

We created a simple document that drives our effort and makes it easy to find answers when we're wondering what we should be working on. It's inspired by a mix of our experience at Atlassian, Salesforce V2MOM and OKRs.

It's a straightforward model designed to be easily understood and quick to adopt.

Purpose at the top

The first section of the document defines our purpose as a company. This is something that should last a few years. We're still iterating on our mission statement but it goes something like that:

Bring teams together to solve big problems

It should be precise enough that it sets a clear direction, but loose enough that it doesn't stifle innovation. I'd recommend taking some time to figure it out because everything else will come down from it. Using the 5 Whys and the Jobs To Be Done is a good start, but if you're like us you'll probably do several iterations as you get to know your customers better.

Focus areas underneath

Below the purpose, we've listed our big priorities for the next 12 months. There are still no metrics at this stage. Instead, we list 2-3 focus areas that will drive our roadmap for the year.

In our case we have:

Don't run out of money: we're a young bootstrapped startup so managing our cash flow is critical.
Land teams: we love it when individuals use Tability, but we're building it for teams primarily.
Awesome goal-tracking: we could expand to goal-setting but we want first to do excel at goal-tracking first.

These focus areas are fairly large and will help pick initiatives for the next 12 months. It's what we often go back to when we're putting things on the backlog. Does it help with cash flow? Does it make teams sticky? Is it making goal-tracking easy and great? If there isn't a positive answer for any of these question then it's probably not a good fit.

Measures at the bottom.

Finally, we have set 2-3 measurable goals per focus areas to help us track progress. I won't give you our exact targets but the overall document looks like the picture below.

Good goals are hard to define. It's often easy to fall for vanity metrics that do not really challenge your business. Metrics do not exist to make you feel good. They are here to make sure that you're achieving the results you need, or at least help you realize that you might not get there with your current approach.

Once you've picked a set of metrics, just run a few scenarios to double-check that they'll help you know the truth. For instance, if you focus on the growth of accounts instead of the growth of active accounts you can easily get a false sense of accomplishment if you see a lot of people signing up. But if most of the newly signed users never return to your product then your business will quickly go underground.

Overall I'd suggest not having more than 10 driving goals in your document because the more you have, the more you're going to dilute your effort. It's better to have a great impact on a few things than having lots of small improvements in different areas.

Split things into quarters

Now that our PFM doc is set up we can use it to drive the roadmap. At the beginning of each quarter, we look at what we can do to maximize impact in each of the focus areas. We always have a clear view of the next 3 months, and an outline of months 3-6. Beyond that, we can just refer back to our strategy document to understand what our priorities will be.

The goals are roughly the same as the ones in the PFM but the targets are adjusted for the quarter.

Measure, learn, adjust - on repeat

Now, this is what truly makes a difference. Creating a vision document, setting some goals is cool. But the real value is in tracking progress regularly. This is quite different from having a weekly demo, or weekly standup where you talk about what you've done in the week.

We update progress on our quarterly goal every week. It's a simple update with a red/yellow/green status as well and how far we are from the target. This is a bit akin to applying Continuous Delivery to strategy, and providing updates on a weekly basis has several benefits:

It helps us realize pretty quickly if we're stagnating in an area, or if something is in the red
It keeps us accountable and softens the noise that happens during the week.
It helps us be more responsive and agile.

More importantly, it helps us drive a culture where we focus on impact rather than tasks.

Adopting the PFM

I created a Google Sheet with a PFM and a goal-tracking template which should be enough to get you started.

Obviously, we're also building a great tool to help teams track their goal. So if you're looking for something better than a spreadsheet, you should sign up for Tability. It includes automatic reminders, an accountability bot, and makes it easy to share updates and visualize progress.

I'm always keen on learning from other teams so please share your own approach and feedback in the comments, and you can always reach out to me on Twitter.

This post was first published on https://blog.tability.io.

Squadlytics is on ProductHunt! Applying CI/CD principles to organizations

Sten — Tue, 06 Nov 2018 11:18:20 +0000

Hey all! It's an exciting day for us at Squadlytics as we've just launched on ProductHunt. It's been a lot of sweating and perseverance to get there today, and it's really cool to reach a ProductHuntable state.

We're building a continuous feedback platform to help teams stay focused on their goals and share progress easily. The basic idea is to bring the benefits of Continuous Integration to track the health of projects.

There's a lot of friction today in the way people share goals and results. You have to find the right spreadsheet or doc, update a column, lose history. And if you're something like Jira or Trello for it, you often end up with a custom setup that is hard to share across your organization.

At Squadlytics we're working hard to keep things simple and create fast feedback loops. If we can remove that friction and accelerate feedback, then it is much easier for teams to address the issues preventing them from reaching their objectives.

Check us out at https://www.producthunt.com/posts/squadlytics-2 - we're eager to get your feedback!

How we measure simplicity to make sure users can do more with less

Sten — Thu, 04 Oct 2018 12:07:18 +0000

I hesitated to share this post here because it's more about UX than really teaching something new about software development. I thought it'd still be relevant as we're all building experiences at the end of the day.

At Squadlytics we have a strong commitment to simplicity. Heck, I'll go further and say that this is our raison d'être, and we've put a little framework together to help measure friction in our product.

Wait, what's Squadlytics?

Our platform helps teams stay focused by providing continuous feedback on goals and results. Most of the teams we talk to have goals they care deeply about. They worked hard to figure out the best path forward, and they strive to deliver their best work.

But as they grow it becomes difficult to share progress and get visibility on how people are doing. You're either using a spreadsheet, which gets lost among all the other docs of the company. Or you have to set up heavy-handed performance management systems, which can be complicated to use and slow the feedback loop.

We believe we can make our users happier with a simple, lightweight solution. We want to help teams know what the priorities are, and how they're progressing. Then we get out of the way.

How we treat simplicity as a feature

Defining a framework to measure simplicity

When you release a new capability, it's reasonably easy to measure its success. You look at the analytics events and compare that with your expectations. It's straightforward to measure the impact of things that are added to a product.

But when you talk about simplifying things, removing behaviors, it's hard to understand how much you're moving the needle because we lack metrics for that. It's much easier for us to quantify outcomes (how many users signed up) than processes (how much effort did it take for the user to sign up).

Rather than coming up with a complicated formula, we decided to look at 2 things in our case:

How many clicks does it take to complete a step?
How many times do you switch context?

We then weighted both actions and decided that a context-switch would be 3 times as painful as a click. This is purely arbitrary and could be debated, but the goal was to reflect that having to go from one screen to another is much more annoying than clicking around the same page. So we end up with this:

Friction Index = Clicks + 3 x Context-switches

Defining the user flow

Once we had the framework, we had to pick a user flow to measure. We did not want to stop at the bare minimum after signing up. Repeating some core actions would give us a better understanding of what our users go through.

If you stop at one instance of each action, you can easily be under the illusion that your process is good enough. But if creating a page takes a dozen clicks, it will quickly become a pain if it's a task performed often in your product.

So our scenario was the following:

A user (you) wants to sign up for Squadlytics to give it a try with 2 colleagues, Joe and Jane.
They want one project with 2 goals (1 for themselves, 1 for Joe).
They want a sub-project with 2 sections and 3 goals (1 for themselves, 1 for Joe, 1 for Jane).

This flow would allow us to cover the signup, onboarding, goals creation and invites. It does not take into account the second user experience on purpose as we're focused on the first user.

Establishing the baseline

We measured our Friction Index (FI) 2 weeks ago, and the results are below. Note that we counted the max number of clicks instead of going for the optimal path. By that, I mean that even when you could press enter to submit a form, we would use a click to submit it instead.

#	Step	Clicks	Context-switch	Context-switch weighted (x3)
1	Signup	4	3	9
2	Email confirmation	6	5	15
3	Create your profile	5	1	3
4	Create your workspace	3	1	3
5	Create your first project	1	2	6
6	Create goal for yourself	8	2	6
7	Create goal for Joe	8	0	0
8	Create sub-project	2	2	6
9	Create goal for yourself	8	2	6
10	Create goal for Joe	8	0	0
11	Create new section	4	0	0
12	Create goal for Jane	8	0	0
	Total	65	18	54

Honestly, when I saw these numbers for the first time I couldn't believe that it was taking 65 clicks and 18 screens to go through this simple flow. 🤯. Here's another way to see that data: each step circle is proportional to the number of clicks or screens involved.

That really made me feel bad, but we had something to work with. Our FI was 119 and we needed to reduce that number.

Things we did to improve the user experience

Reduce context-switching

It's generally useful to take the user through a step-by-step process the first time they use your products. But it can quickly become painful if you keep that heavy flow for repetitive actions.

One example for us was the creation of new projects where we were taking you to a project form, and then back to the newly created project. We changed our approach to automatically generate the project as soon as you'd hit the create button. You could then edit the project title and other settings directly from the page itself.

Better inline-editing

A great thing about spreadsheets is that you can just click on a cell to update its value. This is far much easier than having to show up an entire form with multiple entries when the user only wants to change one parameter.

We implemented inline editing in our project view so that you could change most of the goals, sections and project parameters without having to go to another screen or trigger a popup.

Pick defaults values

Instead of always asking the user to fill in all the fields when creating goals, we would keep the previous values entered for the owner, score and deadline. That helps reduce the number of clicks required when creating multiple goals in a sequence as there a high chance that some of these values stay the same.

Focus on the right fields

A lot of the clicks were wasted on clicking on the first field of a form. We switched to auto-focus wherever it made sense. Once again it may look like nothing, but at scale it can become a UX burden.

The result

After 2 weeks of work, this is how the metrics improved.

#	Step	Clicks	Context-switch	Context-switch weighted (x3)
1	Signup	4	1	3
2	Email confirmation	5	5	15
3	Create your profile	5	1	3
4	Create your workspace	3	1	3
5	Create your first project	1	2	6
6	Create goal for yourself	4	0	0
7	Create goal for Joe	6	0	0
8	Create sub-project	3	1	3
9	Create goal for yourself	4	0	0
10	Create goal for Joe	4	0	0
11	Create new section	6	0	0
12	Create goal for Jane	6	0	0
	Total	51	11	33

Our new Friction Index is 84, which is a ~30% improvement on the previous experience. It still too much if you ask me, and a lot of that has to do with the email confirmation step. But I'm super happy to see that we cut in half the cost of creating goals and projects since it's something that people will often do with the product.

Visually we can see that fewer steps involve switching context and we reduced the number of clicks in many places.

Data doesn't tell all the story

It's important to not blindly look at the numbers and set lofty goals without understanding context. If you look at the absolute numbers, it removes all the complexity of the user experience, and it doesn't help understand the investment required to keep things simple.

It's important to dig into the details and look at what's happening in each step. In our case, we have highlighted the email confirmation step. That's because it means we lose control of the experience at that point and things can be much worse than what we think.

Another thing is that a lot of the ideas to reduce friction came from talking to our users and observing them working with the product. Sometimes you can't cut corners, and it's better to have a couple more clicks, screens or steps to explain the value of your product. Other times you'll notice that you created new pains without realizing it.

Enabling users to do more with less effort

As I said in the intro, simplicity is a crucial feature for us. It's how we distinguish ourselves from the market, and it's essential for us to make sure we're helping our customers to get more things done faster.

If anything, I hope that this post will encourage you to take a look at your product and try to measure your own friction index.

Squadlytics is a continuous feedback platform that helps teams keep projects on track. We remove friction from sharing goals and make updates easy to do.

A simple tool to promote trust in your company culture

Sten — Fri, 21 Sep 2018 07:28:59 +0000

A week ago I wrote a blog post about switching to a trust-based culture that seemed to have resonated with the dev.to community. This was a bit unexpected, and a few people ended up signing up for our service after reading that blog post. So today, I thought I'd be a bit more formal and explain why, what and how we're building Squadlytics.

Start with the why

Over the past couple of years, technology has significantly evolved to give us more flexibility. Collaboration tools enable async work, Slack helps us stay connected, conf calls are easier than ever. The need to be in the same space at the same time to work is fading away, and people are rightfully looking for better work arrangements.

Remote work and flexible hours are becoming the ultimate perks that companies can offer to attract and retain talent. On top of that, it's also a great way to support people that can't do 9 to 5 and level the playing field. The traditional organization with complex layers of management is disappearing in favor of smaller autonomous teams that can execute better and faster. But that means that we need new tools to promote the vision of the company and make sure that we're all working towards the same goals.

What's the easiest way to keep projects on track?

Here's a classic scenario. You meet with your team a couple of weeks before the beginning of the quarter and do a few intensive workshops to decide what your goals are. Everybody is aligned, and now you go to get sh*t done. But after a few weeks, barely anyone can remember the objectives that were set. Focus starts drifting away.

The easiest way to prevent that is to repeat the strategy, repeat the goals, early and often. It sounds boring, I know, but it's effective. Everybody gets busy, and many unforeseen problems will pop on our roadmap. That is why we need periodic reminders of the "why"s because it's really hard to be both solving a problem and thinking about why it's there.

What we've built to help with that

We started Squadlytics to help teams switch to a better work culture which would empower people to achieve goals. And what we ended up building is a tiny, lightweight reminder engine.

I know, it sounds silly.

But we wanted to achieve a few things:

Keep the tool simple so that it doesn't become a chore.
Make it accessible to everyone in the organization and avoid domain-specific language.
Make it easy to share with other teams.

So, in a nutshell, Squadlytics is a goal tracking platform that sends reminders to make sure that (a) you know your goals and (b) you know how much progress you've made and (c) you know your team/company priorities.

To use Squadlytics you just need to do the following:

Create a project
Set some goals with owners
Add update every week (or month/quarter)

We kept the updates super simple, using traffic lights colors to indicate if you're on-track, at-risk or off-track.

Last but not least, we have a bot that will chime in to send you reminders, and that will downgrade the status of your goals if you forget to update them 😬. We're still experimenting with this, but we're trying to add built-in mechanics to help keep teams accountable.

Sign up for our beta today

While there's still a lot for us to do I'm super proud of what we've done so far. Tracking goals is only the tip of the iceberg for us, and we aim to promote better ways to work.

You can sign up at https://app.squadlytics.io, and don't hesitate to add a comment or email me at sten@squadlytics.com if you have any questions.

(you can also check the main website at https://squadlytics.com)

Focus on outcomes, not hours spent in the office

Sten — Wed, 12 Sep 2018 15:50:18 +0000

There are many blessings in being a remote team, but one that I like particularly is that you can't check over your shoulder to see who's in the office.

Empower people with goals

If you focus on hours, you'll get what you want: people will show up on time, and leave after you. But you're promoting the wrong thing. You're signaling that it's more important to be around than to create something that matters. The primary drive for giving people an expected set of office hours is because you're deriving a certain amount of value from it - if I ask the team to work from 9 to 5, then we will be able to achieve this much.

A better approach is to go the other way around. If you give clear goals and give people the means to achieve them, then it doesn't matter how they organize their agenda as long as they deliver what everyone agreed on. That's especially important if you want to be more inclusive as not everyone can give you a straight 8 hours day.

Another thing that happens is that you will scale your ability to delight your customers. When people are given goals instead of tasks, they care more about the outcome. There may be times when you'll look at the solution and will believe that you had a better idea. But if you give people room to make mistakes, then you give them room to grow. And it won't be long before your team starts moving much faster, while you can focus on other things.

Negative outcomes are valuable too

One rebuttal for focusing on outcomes is that it can be understood as ignoring effort. But a negative result is still a result. Building a product can be seen as an iterative process that consists in being less wrong about what people want over time.

Bad outcomes should be accepted as long as you learn from them. You should always do a post-mortem on projects, and try to understand what went wrong. It can be that the concept was poorly defined, that you didn't have enough resources, that external factors impacted the timeline, and yes, sometimes it will be because someone did a poor job. But more often than not, there will be many reasons why you didn't get the expected results, and it's rarely the fault of a single individual. So learn, fix, and repeat.

Embrace a remote team culture, even if you're in the same office

Remote teams are forced by nature to document things, to communicate more, to be open. But more importantly, remote teams have to build trust and discard micro-management in favor of creating a strong culture where the vision, values, and goals are shared broadly.

Get your end-to-end pipeline ready before coding any features

Sten — Fri, 31 Aug 2018 09:20:34 +0000

When you get a great idea (and after it's been validated), the next thing is to start building your MVP. But instead of implementing any of the required features, it's best to begin by shipping a "Hello World" to production.

Late deployment pipelines are costly

A lot of teams have adopted Continuous Integration because it allows them to move faster. By integrating the work of everyone early and often into the mainline, you reduce the risk of conflicts and you make it trivial to understand what is breaking.

The same thinking needs to be applied to deployments. Every week you're going to be solving small configuration problems. Missing dependencies, env variables, service configuration, monitoring tools... As you add more features to your software, you will also increase the amount of configuration required for it to work. If you wait until you're satisfied with your local tests to release your app then you're likely to spend a significant amount of time figuring out how to set things up in a public environment.

The better approach is to start with your classic "Hello World" and to ship that in what will be your production. It doesn't matter if it's on mobile, desktop, web. Just make sure that you know how to deploy what you're building. And then deploy your work early and often, every day if you can.

You will drastically reduce the risk of releasing and, while it looks like slowing down at the beginning, it will make you move faster. Some platforms have hard constraints on what you can ship, and you want to figure that out right from the start instead of having to refactor your code down the line.

Ship early, get more feedback

Now here comes the real benefit. We tend to vastly overestimate how finished our work has to be before we can show it to others. So we keep adding features after features. And then at some point, we judge it ready and put it somewhere where others can play with it.

Having your application being accessible early will help a lot to fight that tendency. Of course, it's best to keep things private until you can safely onboard people, and there are many ways to do it:

Private URLs
Password protection
Unlist your app on marketplaces

But the point is that you want to be able to pull out your phone or your laptop at any moment and show what you're working on. The more feedback we get, the better we can make our products. And this is also a great way to get early adopters.

Build stories, not features

Sten — Wed, 15 Aug 2018 20:18:31 +0000

We all want our data to be protected. And one way to solve that problem is to have a password-protected account, but no one gets excited at the idea of having another set of credentials to manage. Being safe is the story, and having a password is the feature.

Stories vs. Features

Almost every capability in applications can be described as a feature. You create an account, add content, connect with your friends, etc. Apps are made of dozens, hundreds, or even thousands of pieces that interact with each other to help users achieve particular goals.

Yet, it is important to think at an abstract level if we want to be successful at delivering great experiences. We need to frame our vision high enough that there can be many possible answers to the problems we're trying to solve. And those answers will end up being the features that we implement.

If we look at Shopify for instance, they do an excellent job on their website of emphasizing their stories, and then listing the related features beneath.

The story: you can control your brand
The features: custom domains, themes, customizable CSS

A simple way to move up the ladder when you have a feature in mind is to use the 5 Whys. It'll naturally force you to go back to the root issue that you need to address.

Why it matters

We always have a plan. But many things can delay or halt projects. It might be poor management, some unforeseen technical constraint, or difficulties in syncing multiple streams of work. So, you'll need flexibility if you want to keep delivering value to your users. If you're using agile methodologies, it will help you realize faster when you're off-track. But that's only helpful if you can then act on that information.

Having an overarching story guiding your roadmap will make it easier to change scope or switch priorities. In the case of Shopify one goal is to help customers bring their brand with them. There's plenty to chose from if one particular feature happens to be more complicated than expected. You can still fulfill the original goal while changing the set of capabilities delivered to the users.

Thinking in terms of stories will also help you be more creative in your solutions. Today we can just look at our phones to unlock them - we use our faces as passwords, and there's no need to type things in anymore. Of course, we had to wait for the right technology to be available. But it is also because someone took a higher perspective to look at the problem.

Stories are powerful

At Squadlytics we spent a lot of time early on to define what our purpose was: to help teams keep the pulse on their projects. We shipped some pretty cool things while going through our first iteration. But we soon realized that it was not going in the right direction.

I'm quite sure that without that vision we would have been stuck with our heads down, shipping features after features, and creating a solution in search of a problem. Instead, we were able to go back to the drawing board and design a much better platform.

Stories will clarify your message, and narratives are far more persuasive and inspiring than a long list of capabilities.

Local development with HTTPS on OSX

Sten — Sun, 15 Jul 2018 14:50:48 +0000

A good rule of thumb in software development is that you should try to be as close as possible from your production environment. Doing so helps you avoid common mistakes due to discrepancies between your local dev setup and your prod configuration. Containers are really helpful to mitigate some of the dependencies issues, but one thing that has always been a PITA for me is using HTTPS for local development.

At Squadlytics we have a React app for our UI and a Rails API backend where we force the use of SSL. We've tried many things to find an easy way to use HTTPS for local development, and we finally found a solution using a proxy and dnsmasq. I'll share here how we're doing things, but first, let me present you the alternatives that we explored.

Option 1: Generating certificates ourselves

We started by looking at generating our own certificates for local development. First, you need to create your own Certificate Authority. Then you use that entity to build your development certificates.

There's a great tutorial written by Brad Touesnard that you can read if you want to go down that path. It looked great at the beginning, but it started to become cumbersome when we had to figure out custom starting scripts for the backend and the frontend to use the right certificates.

We had to do a few different takes to get it right, and we ended up looking for a simpler solution where we wouldn't have to manage the certificates ourselves.

Pros: Once it's done it just works.
Cons: A bit hard to setup and manage.

Option 2: Using ngrok

If you're not yet using ngrok chances are that you'll need it sooner or later. It's a neat tool that allows you to create tunnels to expose your local dev machine to the web. The typical use case is to test webhooks, but you can also reserve your domains and generate SSL tunnels to your dev environment with either a subdomain (https://subdomain.ngrok.io) or use your own dev domain for it (https://api.squadlytics.dev).

It minimized the configuration on our side. You only need to install ngrok to get it working - and you won't be getting certificate errors in your browser.

But problems start if you need to share dedicated URLs. For instance, if your backend API is accessible at https://api.ngrok.io, you can only tunnel this URL to one local dev machine. To my knowledge, you'd have to reserve custom domains for each developer to solve that problem (https://api.john.ngrok.io, https://api.jane.ngrok.io) and probably do some tricks in your code to support that. On top of that, every request needs to go through ngrok which slows down development and prevents you to code while being offline.

So we ditched ngrok as it would not scale for our local SSL dev issue. I want to emphasize here that it's a great tool, and it's mostly our fault for trying to stretch it too far.

Pros: easy to get started, great for testing webhooks
Cons: slow for development, doesn't scale for continuous use

Option 3: local-ssl-proxy + dnsmasq

We looked back at the constraints we had for local development to simplify our problem:

We needed to be able to hit specific domains for the API and authentication.
We were using subdomains for workspaces (à la Slack) and therefore required to access a wide range of subdomains locally.
We needed all the requests to be done via HTTPS.
We wanted to have something quick to set up for extra services, and easy to install for new developers.
Being able to code offline would have been a big plus.

With these goals in mind, we settled for a simple solution using a proxy server and a custom local DNS server.

local-ssl-proxy

local-ssl-proxy is a npm package that starts a simple SSL HTTP proxy using a self-signed certificate. We created a small configuration file to map the Rails backend and the React frontend to different ports for SSL.

{
  "Rails backend": {
    "source": 3001,
    "target": 3000
  },
  "React UI": {
    "source": 8090,
    "target": 8080
  }
}

With that configuration, we could use https://api.squadlytics.dev:3001 and https://acme.squadlytics.dev:8090 to have access to use the platform via HTTPS. No need to create a custom starting script for Rails or figuring out how to pass a certificate to the React app.

Adding new services would be as simple as adding a new entry in that configuration file.

dnsmasq

The other problem we needed to solve was to support a wildcard domain to avoid having to create multiple entries in /etc/hosts. Thankfully you can use dnsmasq for that and create a local DNS server with your own rule.

You can follow the instructions in this Gist to see how you can set it up on your machine. In our case, we created a bash script to do it all at once.

You should be careful not to set a wildcard domain for all .dev domains as this is a real TLD. This is why we've restricted our config to only map .squadlytics.dev domains to localhost instead of supporting all URLs using .dev.

#!/bin/bash
echo "1. Installing dnsmasq"
brew install dnsmasq
echo "2. Configuring *.squadlytics.dev local domains"
mkdir -pv $(brew --prefix)/etc/
echo 'address=/squadlytics.dev/127.0.0.1' > $(brew --prefix)/etc/dnsmasq.conf
sudo cp -v $(brew --prefix dnsmasq)/homebrew.mxcl.dnsmasq.plist /Library/LaunchDaemons
sudo launchctl load -w /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
sudo mkdir -v /etc/resolver
sudo bash -c 'echo "nameserver 127.0.0.1" > /etc/resolver/dev'

Some people recommend using a fake TLD (like .test), but services like Google require real TLDs for OAuth.

Don't forget to add your localhost as a DNS server in your network settings otherwise it will not work.

Bypassing the SSL certificate errors

The last step for us is to bypass the certificate errors that will be inevitably thrown by your browsers.

If you're using Safari, you can just accept to visit the site in the error screen. Just make sure that you do that not only for your UI but also for any API that is used by the client.

Chrome seems to be much more strict, and to this day I've only managed to bypass the errors by launching Chrome with the --ignore-certificate-errors flag.

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --ignore-certificate-errors &> /dev/null &

I hope this will be helpful to some of you. You can check our config scripts in our repo at https://github.com/squadlytics/local-ssl-development. If you have questions or suggestions, please don't hesitate to write a comment.

Photo by Liam Tucker on Unsplash