There is one small thing that made my life as a software developer a little better. And not many people seem to know about it.

The trick is hotkey terminal window. It is basically an additional terminal window that is always visible, and you can show/hide it using a keyboard shortcut.

This additional window seemed to be really handy as a code scratchpad or dedicated man window. It is so convenient that I sometimes use it as themain terminal.

I believe this feature should be available on most platforms. I personally use iTerm2 (Mac only, sorry) and it has this functionality built-in. In my case, the new window show/hide up after I press CTRL two times.

Quick terminal tip was originally published in The Runway on Medium, where people are continuing the conversation by highlighting and responding to this story.

We started with a process closely modelled after Intercom’s. They had a team six times as large, but what they wrote about rang true. So we adopted it as is.

Five months later we had to scrap everything and start from scratch. Our product was nowhere near done. The team was consistently underperforming. Everyone was frustrated.

So what went wrong? For one, getting from nothing to a minimum viable product takes different skills and processes than developing an existing product. And two, until you understand the jobs to be done in your team, it’s unlikely that any process will work.

If you’re struggling with the same problem, here’s what worked for us.

We created a list of user stories for our process.

We wrote down things that need to happen, on regular basis, for the product to move forward.

Expressing them as user stories helps you understand what needs to be done and why. Here are a few examples:

• As a developer, I need someone to review my code so I can improve my programming skills and maintain or improve the overall quality of our code base.
• As a designer, I need to clearly understand what a particular feature of the product should do, so I don’t have to re-design it over and over again.
• As a product manager, I want to know how much the team can done this week so I can correctly communicate our progress to the rest of the company.
• As an engineer, I want to be able to frequently deploy to production without having to worry about breaking something.
• As a product manager, I want to capture ideas and product feedback so I can incorporate them into our roadmap.

We ended up with a list of 20 or so processes like the ones above (although written in a slightly different format).

We started with something simple.

Instead of adopting a complicated workflow or methodology, we started with a minimum viable process based on the initial set of user stories.

This wasn’t a collaborative effort. I sat down and put together a set of tools and processes (mostly meetings) that I thought would work, explained to the team how we’re going to work, and we were off to the races.

Getting started right away, even if our process wasn’t perfect, was what made this whole thing work. Design-by-committee would’ve let to days or weeks discussing what an ideal process would look like. We got two weeks of solid product work done instead.

This initial momentum was important. I helped us stick to our process. Most habits (including things like diet) get abandoned because people don’t see results early enough.

We built in feedback loops and iterative improvement into the system.

The process we started with wasn’t perfect, but it had two things going for it:

1. We knew exactly how we’re doing because we measured our velocity on weekly basis.
2. We had a mechanism for capturing feedback and issues with the process, and a way to resolve them.

We keep a project in Asana called Product Retrospective where everyone can report feedback or ideas about how our team is run. We go through the list every two weeks, everyone nominates issues they’d like us to focus on, we discuss possible solutions and assign tasks to put them in place.

So even though our initial process wasn’t perfect, it was getting better every week. And we didn’t waste time fighting over process because everyone knew that if they want to change it all they need to do is wait until our next retrospective and bring it up.

These two mechanisms, coupled with a very simple process that we monitored on daily basis, helped us get from something we felt was unshippable to a live product in 3 months. After another three months, our product was further away than we thought it would be in a year.

We are still working on it.

Our process still isn’t perfect. It never will be. But over the past 5 months we ran 10 retrospectives, each making the way we work a little better. And because these improvements compound over time, we’re getting more and more done with less effort.

Hopefully this helps you avoid the mistakes we’ve made. Building a product team is hard. We are learning every week and we are by no means perfect. But we’ve created a culture of continuous improvement that applies not only to our product but also our team.

If you’d like to share your story, please email me at matt@pilot.co.

Pilot Blog

Lessons learned from building a product team was originally published in The Runway on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s a lot of discussion going on on the web about whether chatbots are really the next big thing or just a short-term fad. Since I’m the co-founder of Ada, a personal assistant for real estate, I’m obviously biased — but don’t be mistaken, the dilemma is a huge topic within our team.

Certainly, artificial intelligence will change the world — no question about it. But it’s still unclear whether the technology for building intelligent agents is ready for mass markets right now, and whether conversational interfaces are a good choice given the current features of our smart devices.

Chatbots are cheap at first.

Last month, I wrote that developing a chatbot is a fairly cost-effective approach to building a prototype using the Wizard of Oz technique.

I stand by what I said. Serving first customers with a chatbot will provide every early-stage startup with a tremendous amount of learning, feedback and market insight — but it’s not the entire story.

They quickly start getting expensive, though.

As you go down the road, the technology will start costing you a lot more than it did when you employed human operators.

Why? AI development requires hiring great engineers and researchers, having broad knowledge about current state of the art, access to cutting-edge tools — and sometimes inventing new ones as you go.

They aren’t cheap anymore. (Not right now, at least.)

Should chatbots be just better, simpler apps?

Dan Grover, a product manager at WeChat, raised more doubts with his influential post, “Bots won’t replace apps. Better apps will replace apps.” He noticed that while the chatbot trend emerged in the West as a response to the popularity of WeChat and Line in Asia, both of these apps took a very different approach to the topic.

Connie Chan on Twitter

6/ THIS is what a WeChat transaction actually looks like (ordering McDonalds); not a chat but an app-within-an-app.pic.twitter.com/bEKCBnpuHW

The fact is, WeChat doesn’t employ AI-powered chatbots. They use HTML5 menus and webview interfaces to let partners build simple apps within the chats and use the WeChat platform to streamline identity persistance, payments, offline storage, and data sharing. No intelligent agents involved — just a simple, yet powerful, app-within-an-app.

That’s a bit puzzling since Silicon Valley essentially used WeChat as a proof of concept — but it wasn’t even the same concept.

So, are we on a hype train?

Chatbots need new product metrics and new UX frameworks.

If there’s no proof of concept yet, then the bot business is just the new Wild West for technology and products.

To restrain it, we need to lay some groundwork.

• Just as we have product metrics such as DAU and business metrics like LTV to keep our products and business models in check, we need new exhaustive metrics to determine whether building a bot is really a logical choice or just a caprice.
• Similarly, we need new UX frameworks to guide our decision making based on the metrics we’ll invent. These frameworks should help answer a single question: if a chatbot is indeed a good choice, how should we build it?

These metrics will help us understand the business of making intelligent agents and personal assistants just as we understand building new SaaS businesses or creating new mobile apps today.

If we put things this way, 2016 is nothing more than a new 2006. Maybe time really is just a flat circle.

Enter cognitive ergonomics.

Let me give you an example of what I had in mind.

Last month, I read a great piece on cognitive ergonomics and, particularly, cognitive efficiency:

Cognitive Efficiency […] is a measure of how much cognitive effort is saved through the interface. For example, compare […] alternatives to getting calendar information for something 2 weeks away. In the first, a user has to exit a messaging platform, open a calendar, scroll to the right day, and find the event on the calendar. In the second example, a user can ask […], right from a messaging platform, a question about the day, or the event, thus saving several steps.

— Rob May, Cognitive Ergonomics and Chatbots

Measuring cognitive efficiency is a great example of a user experience metric that we can use to create an extremely simple framework.

1. Given a task, create two prototypes that help a user solve the task: one bot-based and one (pretty standard) app-based.
2. Measure cognitive efficiency for each prototype.
3. Choose the prototype that solves the task better.

You can even mix the bot-based approach with the app-based approach — just like we do at Ada. We’re building a hybrid product that switches between an SMS chatbot and a mobile web app based on the task we need to solve. As we found out, there are three tasks at which bots excel in our case:

Bots are great at onboarding.

Bots are an excellent acquisition channel and since they don’t require the user to learn new UI, they help maximize retention after registration. The most notable example is perhaps the Slackbot.

Bots facilitate discovery.

An intelligent agent can help you a lot when you don’t really what what you’re looking for. For example, when users hire Ada to find a new apartment to rent, we can help them decide on their criteria based on local market information and real estate trends.

Bots can use SMS notifications naturally.

Text messages have a 98% open rate which results in tons of engagement.

There’s still a lot to be done, of course, and the article above is by no means a full solution — but I hope it answers some questions regarding chatbots, intelligent agents, and conversational interfaces.

If you have any questions, ideas or concerns, feel free to hit me up on Twitter or Snapchat.

Pilot Blog

The Chatbot Dilemma was originally published in The Runway on Medium, where people are continuing the conversation by highlighting and responding to this story.

Do you work at an early-stage startup, especially a service startup? Cool. Let me tell you why you should be interested in messaging bots — a huge, huge trend — even if you haven’t considered it because you wanted to build a web or mobile app.

Messaging is cheaper.

For startups on a shoestring budget apps cost a lot. Full-blown delivery teams need designers, engineers — both front-end and back-end — and testers… That’s a lot of man-hours even for a small project.

Messaging bots only need a bit of back-end tech to get started. In the beginning, you don’t even have to worry about all that AI-related stuff such as machine learning or natural language processing.

If your service is yet to get substantial traction, you can always put a trained operator behind the wheel — a technique known as Wizard of Oz prototyping.

In a typical Wizard of Oz scenario, an unaware user believes that a fully functional application system exists. There’s no harm done if the user still gets a meaningful result from the fake prototype. You, on the other hand, don’t have to hire any front-end developers yet, because the front-end is already handled for you by messaging platforms such as Facebook Messenger, WhatsApp, Twitter or SMS. You just need a good copywriter.

If you’re a technical co-founder, or you’ve got one on your team, you’ll probably do fine without additional back-end engineers as well since you only need to set up some kind of interface to talk to your users as the wizard. That’s huge advantage over your competition.

Messaging works cross-platform.

You often have to cover at least two or three platforms — web, iOS and Android — to reach a meaningful number of your potential customers. Every single platform adds some management and development overhead as a cost of supporting it.

It’s actually quite easy to make your messaging bot cross-platform. After all, it’s just text most of the time. As long as you don’t need to get fancy with custom integrations, you only need to build a universal text recognition service that acts as an adapter and connect it to any messaging platform you want to support.

Messaging platforms speed up development.

Consider the following scenario. You’ve built an app that recommends the best burger recipes sent by your users. If one of them wanted to add a recipe for, say, pizza, you’d have to add new ingredients to your system and present the pictures of pizza a little bit differently than pictures of burgers — all that would be included in the new release next week.

If you had built a messaging service, you’d only need to receiver a recipe for good pizza from the user and sent it to others via text. That’s 5 minutes of work tops. And if the community didn’t like this whole pizza thing, you wouldn’t have to abandon an entire week’s worth of work in order to serve only burger recipes again.

Messaging bots will let you respond to customer demands much more quickly, because texting users generally accept a lower quality threshold than on other platforms.

They value authenticity and utility over polished details. And thanks to the aforementioned Wizard of Oz technique, you can roll out new features much faster, working on a better version behind the scenes.

Need proof? At Ada, my team and I are building an AI-powered concierge bot who can help you rent your next apartment. Day by day, we have to face a constant stream of new requests from people looking for their perfect flat. Slowly but steadily, we’re automating the most popular ones and respond to the unusual ones by hand to keep our customers delighted.

Messaging is a direct two-way channel for contacting your customers.

There are two reasons for why this matters. The first reason is that customers value experiences that feel personal — and what’s more personal than your own concierge bot available on your mobile phone?

The second reason — and one that’s much more important in my opinion — is feedback. Messaging bot teach your users to respond to them frequently. That’s an enormous advantage for early stage startups who often can’t figure out why they face customers’ indifference. For example, if they stopped using your SMS bot, you’d be always able to send them a quick text to ask why. In fact, you can ask them anything and they’ll consider it a normal part of the experience, not a boring questionnaire. And you’ll be able to adjust to their feedback much better.

It’s been known for a while that messaging and bots have become trendy, but they also offer certain advantages as a temporary measure to entrepreneurs who don’t want to invest in messaging in the long term. They can simply treat it as a faster way to build a prototype to confirm their hypotheses — and then use what they’ve learned to build a full-blown app. That’s the additional value of that new bot-driven paradigm.

Psst, have you seen the Pilot bot for Slack?

Pilot Blog

Why messaging bots are perfect for early-stage startups was originally published in The Runway on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cucumber is a Behavior-Driven Development style software tool. If you’re not familiar with it, here’s its main advantage in a nutshell:

Cucumber scenarios can be read by anyone on your team. And because they can be read by anyone, you can use them to help improve communication, collaboration and trust on your team. 💪

Here’s an example:

   Given a bus with a number 144 that’s nearby the Main Street stop
     And a bus with a number 122 which is 5 minutes behind
    When 144 approaches the Main Street bus stop
    Then the text displayed on the indicator board for 144 should
         change from “1 minute away” to “please enter”
     But the text displayed for 122 should be “5 minutes away”

Personally, I love using Cucumber — and it hurts me to see that it’s often so fundamentally misunderstood. Let me explain why.

Myth 1: Cucumber is a testing framework.

Cucumber does run automated acceptance tests, but it certainly isn’t just a testing framework.

I think this misconception originates from a systematic failure to understand what BDD and its ancestor, TDD, really are. Both processes are test-first design methodologies — but they’re not testing techniques. The objective of testing is to find bugs. The objective of design is to produce a blueprint of code that needs to work.

Kent Beck, the creator of Extreme Programming, a methodology that helped TDD hit mainstream, described TDD’s approach as “code a little, test a little” to write “clean code that works.” In this light, a test is simply a byproduct of TDD’s engineering process; the real goal is well-designed code.

What’s the truth?
Since BDD and TDD share many underlying concepts, Cucumber doesn’t consider tests to be its main artefact, either. It purposely defines itself as a collaboration tool, not a testing framework.

Cucumber facilitates BDD’s process in a holistic, cohesive way that lets software engineers capture requirements using Gherkin’s syntax, then easily turn Gherkin into the system documentation, then execute that documentation with automated acceptance tests to ensure it stays up to date. All parts are equally important.

Myth 2. Cucumber equals end-to-end Capybara.

Inside the world of Ruby on Rails, Cucumber is typically associated with using Capybara for an end-to-end system testing. It’s a fundamentally limiting approach to harnessing benefits of a business-readable DSL like Gherkin.

What’s the truth?
End-to-end UI testing definitely isn’t the only way to use Cucumber. Since BDD is a test-first approach just like TDD, you can use Cucumber for unit testing, too, to create code that reflects a full-blown model of your business domain filled with meaningful real world examples and written in ubiquitous language.

Those familiar with Domain-Driven Design’s approach and benefits will recognize the significance of Cucumber’s focus on the ubiquitous language. It aims to eliminate the cost of mental translation between domain experts and software engineers with their technical vocabulary, thus reducing the number of misunderstandings in discussions between technical and non-technical stakeholders.

Eric Evans, the author who coined the DDD term in his book of the same title, stresses how important it is to design code using the ubiquitous language to build valuable software without rework and domain misunderstandings.

End-to-end testing with Cucumber wastes the benefits of Gherkin’s business-friendly style, because the the ubiquitous language built in scenarios doesn’t have a direct relationship with code. Domain-oriented unit tests will easily let you inject the business domain model into your code — which will improve the design.

Myth 3. Cucumber tests should maximize code coverage.

Hear the truth and let it free you: you don’t have to test everything. Testing every possible use case is a job for QA engineers. But they use different tools to do that — or they use the same tools, but they do it very differently.

What’s the truth?
Spec examples serve another purpose. Since Cucumber is a communication tool, the examples should improve reader’s understanding of what the described feature is about.

There’s no need to employ every possible test heuristic to cover every possible use case. Find the very essentials and describe key examples. You don’t even have to test every class in the system. If a class isn’t related to the business domain and doesn’t bring visible value to non-technical folks, it really shouldn’t be described in Gherkin. That’s noise in the signal.

Many practitioners admit that they were discouraged from using test-first design due to some of TDD’s engineering dogmas. I think Cucumber’s emphasis on non-technical stakeholders helps reduce the over-engineering of your testing stack.

When I say Cucumber and Gherkin improve code design, I don’t want you to think about an overly complex web of intermediary objects built in order to avoid doing anything slow. I want you to think about getting to know your business domain better to avoid future reworks and bugs. Business-focused Cucumber tests encourage such thinking. 👌

Further reading:

• Cucumber is not a testing framework!
• Test-First Design
• Introducing Modeling by Example

Pilot Blog

3 myths about Cucumber and Gherkin was originally published in The Runway on Medium, where people are continuing the conversation by highlighting and responding to this story.

You have a Minimum Viable Product and you’re wondering what should happen next. I presume you also have at least one customer — because if you don’t, all you have is a prototype.

There are few things more destructive to a startup than falling pray to the “build it and they will come” mentality. Here’s my advice.

Put metrics in place.

Start by setting up a spreadsheet with a column for each week. In that column, type in the number of customers that you have on the last day of that week.

It doesn’t necessarily have to be the number of customers. You may find monthly active users or revenue more relevant to the core of your business. Ideally, it should be something correlated strongly with the value that you’re creating for your users.

Measure and repeat.

Create a simple formula that will tell you how quickly that number is growing.

Each and every week update your spreadsheet and look at the numbers of customers that you have. Typically, you should be growing the value between 5–10% per week. This obviously depends on the type of business that you’re in.

If you have enough data, drawing a graph might help you visualise your metrics and spot trends more easily.

Focus on the north star.

Once you have your MVP, from that point on, the only thing that you should be focusing on is making the number go up. Every Monday, sit down with your team and think what is that you can do this week to grow the number of customers (or whatever is the north star metric that you have).

Once you’ve built the MVP, change your mindset: you just do whatever it takes to make that number go up.

Pilot Blog

I have my MVP — now what? was originally published in The Runway on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a founder and entrepreneur, it’s important to spend time and energy on what’s most valuable: building the right product.

To help improve your focus on the vision, you’ve probably considered — or even hired — remote employees. But despite the distance, it’s crucial your team members collaborate with one another effectively.

As a remote company from day one, we’ve learned that the right processes and tools make a world of difference. Here’s how to work better outside the four walls.

Start with a simple onboarding.

Good remote workers typically use their intuition and experience to integrate seamlessly into a team. That said, it’s important to provide input and guidance — at least in the very beginning — to orientate your workers towards the company’s goals.

We’re talking about the nuts and bolts here: what tools to use, when to provide status updates, and so on. Keep the onboarding process as simple as possible, and make sure it reflects your preferred work style.

Document and share everything.

An important habit of any founder, whether working with in-house or remote employees, is to document general company information and make it easily accessible.

This habit helps the onboarding process immeasurably, as a new employee can gather information as and when they need it. It also helps breed a culture of sharing, which will help your business grow and prosper.

Promote direct contact.

When work starts, it’s important that your remote employee has direct contact to a sparring partner — at all times. This can be another designer or developer, a team lead, or even the CEO.

Encourage them to ping this partner on their preferred channel, whether that’s Slack or email, whenever they need help.

Put simply, this approach gets stuff done quicker. Managers are often bottlenecks, and a bottleneck is the last thing you or a remote employee wants. Direct contact is always best.

Organize regular tech talks and demos.

These meetings help the company maintain a strong culture, allow people to learn new skills and stay up to date with other people have shipped. It’s a great perk for remote workers, as it’s their chance to feel included and to say “hi” to people they usually don’t see.

Arrange weekly 1:1s.

As your relationship with employees grows, and as they become more embedded into the company, consider holding regular one-on-ones.

Much like tech talks and demos, 1:1s are a very inclusive experience for people that aren’t situated physically at your office. They let both you and them provide feedback and assess processes, goals, and other company mechanics moving forward.

Meet in person.

If you can, organise a get-together for the entire team at least twice a year. Not only is this the most enjoyable way of meeting all remote employees in person, it’s also a great opportunity to hold a keynote or dinner to discuss the accomplishments and aspirations of the company. It’s all about making them feel included and valued, as well as inspired to deliver great work way into the future.

Use the right tools.

To achieve the very best results, the right people and processes must be teamed with the right tools. Here’s what helps Pilot stay connected, inspired and productive.

Slack
With lots of integrations and customisations, we’ve made Slack our main communication channel. It allows our team to stay up to date with the latest developments.

Google Docs
All of our need-to-know information can be found there. Annotations and superior organisation make it much more versatile than standard Word documents.

Tapes
A picture is worth a thousand words, but Tapes makes our communication even more efficient with short narrated screencasts. Think bug reports, tech support, or attachments to almost anything on screen.

Asana
Asana is a project management tool with everything you need to orchestrate a team. It lets us invite other people to projects and tasks, leave comments that @-mention them, and set priorities and deadlines. We even organize daily standups there!

Google Hangouts
We opt for Hangouts over Skype for its reliability, easy integration with Google Calendar and because it works in the browser. We conduct our employee interviews with Hangouts, and host all of our tech talks and demos there, too.

Working remotely has never been easier. But the most successful products are always built by people whose ideas, emotions, inspirations, concerns are communicated — and worked on — clearly.

Pilot Blog

How to get the most out of your remote team was originally published in The Runway on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today’s most successful products aren’t just built at desks between 9 and 5, by colleagues who live in the same city. They’re built by people from all around the world out of coffee shops, parks and other inspiring places.

⭐️ If you’ve read my previous article, you already know why hiring remote employees is the way go to. Here’s how to do that.

Define key attributes.

Before you get started, you should define what characteristics are important to you and your business. There are 3 key attributes which we put at the top of the list when looking for a remote worker to join Pilot.

Look for outstanding skill.

Are they doing things that others aren’t? Have they worked with any standout companies? Have they created an open source project that’s being used by people across the world? Can you find their name in articles by leading media outlets?

Look for self-starters.

People that work remotely should show signs of motivating themselves and others, of carving their own path. Look for any leadership roles they’ve been placed in, or a proven track record of work on bigger projects — these usually involve strict deadlines.

Also, take note of their career trajectory: have they consistently improved their skill set or level or seniority? The most self-sufficient people have clear ambition to better their craft.

Look for people who need little guidance.

People who pick things up easily, who ask the right questions, who call on their own best practice.

This is typically the result of years of experience, but don’t discredit younger talent — defining new processes, meeting clients, blogging regularly and speaking publicly are all signs of someone who knows what they’re doing.

Pick a reliable selection method.

There are many ways to find and hire remote employees. Some are more effective than others, but each has its benefits depending on how far along your business is.

Employee referrals come first.

This is always our first step at Pilot. Put simply, extraordinary designers and engineers know other extraordinary people. If you already work with top tier talent, ask for recommendations.

Trust your immediate network.

Leaders always remember great workers, and luckily the entrepreneurial world is built on knowledge sharing. Rely on your network for advice and references.

Advertise — but in the relevant places.

Reach the right people by targeting communities that are specific to the role you’re hiring for. For engineers, try StackOverflow and GitHub. For designers, there’s Dribbble and Designer News.

Pick the right marketplace.

You can find the best people in the industry through specialist platforms which carefully vet everyone they work with, so the hard work of finding great people is already taken care of. Pilot is there to help. 😇

Create a thorough screening process.

This is your chance to fill in the gaps on a application, to quiz the person on a methodology they used for a previous project, or to ask why your company is the next logical step in their career.

Have them talk to other team members.

There’s a big chance that the person you’re hiring will know more about the role than you — it’s a mistake to go through the hiring process solo. Ask one of your expert designers or engineers to hop on a call with them. Afterwards, sit together and analyse the person’s information — it’s important that the majority agrees she’ll add value to your business.

Be creative with your challenges.

Delivering a challenge is a good way of seeing how an applicant will react, in a short space of time, to a new brief. At Pilot, we want to see how the person will cope with different time zones, with projects that are only half completed, with collaborating with over 10 different people in the space of a day. In short, the challenges that we, as a company, face every day.

Don’t ignore culture.

You should make sure new employees’ impact on your business and existing team members will be positive. Do some online research and find out what their hobbies are, the types of things they publicly comment on, the kinds of influencers and movements they follow.

Talk about yourself.

Your screening process should allocate time to explain who you are, your future intentions, the working culture you’ve created, and the expectations of the person filling the role. If everything resonates, it’s time to move to the next step. If there’s any doubt, it might not work out.

With time, you’ll find this approach to hiring easier and faster than taking up in-house employees. I hope it will help you build a better team — and ultimately a better product.

Pilot Blog

How to hire remotely was originally published in The Runway on Medium, where people are continuing the conversation by highlighting and responding to this story.

We used to meet colleagues at the office and have meetings around tables. Today, with the myriad apps that allow us to communicate and work with anyone, it’s not the most effective way of doing things.

The office isn’t necessarily a bad thing, and many appreciate the social element of being in one place. The reality is, we’re all working remotely now anyway:

• Different teams sit in different corners.
• We use online tools to collaborate throughout the day.
• We open up new offices in new locations to serve new customers.

Remote working is — and always was — inevitable. And today, it’s the secret ingredient behind some of the most successful products — built by people hired from all around the world, working out of coffee shops, parks and other inspiring places.

Here’s why you should consider this approach when looking out for new employees, based on our company’s experience.

It’s easier and faster to hire remotely.

It’s easy to look up each person’s profile online and explore their past achievements or what they’re working on now — and experienced remote workers will usually have detailed websites and portfolios. You can also find employees by posting an offer on remote job listings, or through Pilot.

When seeking the right person, there’s usually no time to wait for her to get to work — and moving home is a huge time sink for employees that have to relocate.

You get access to the best people in the industry.

If you restrict your search to one particular area, or demand all applicants to relocate, you’re going to dramatically narrow your results. By choosing to hire remote employees, you expose your business to a broader pool of talent.

When compared to in-house workers, they also tend to be happier in their work, which translates into better results.

It’s a scalable approach that suits big and small businesses.

Moving an in-house team every 6–12 months is expensive and labour-intensive. With a remote team, you’ll never outgrow your office. And with the right culture, remote employees can feel just as close as the ones next to you, but function in a much more convenient way.

Remote employees are more cost–effective.

Filling a role yourself might cost you $7000 on average, and over twice that if you use an external recruiter. That’s a massive expense for cash-poor startups, and, if you choose to rely on a recruitment agency, the results may be disappointing — many top designers and engineers simply don’t work with them.

On top of that, if you decide to hire remote contractors, you’ll also avoid the common recipe for distraction: holidays, benefits and stock options.

Working remotely isn’t an experiment anymore — it’s serious business. The sooner you start taking up remote employees, the better they will help you focus on the vision of the product, and not how it’s put together.

Pilot Blog

Why you should hire remote employees was originally published in The Runway on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building a company inevitably involves creating processes to handle routine and non-routine tasks. And most processes suck. They suck because they are often designed with an idealised view of what the work is like.

Just like products, processes need to solve real problems. They are either adopted, or they die.

Trying to overhaul any process all at once poses two major threats:

• It takes more time to learn if it worked or not.
• It’s more difficult for your users (e.g. employees) to adopt it.

You can avoid some of these pitfalls by iterating your processes over time, just like you would with your product.

Document as-is, not as you want it to be.

If you’re already doing something but there is no formal process for it, don’t try to create a process around it and change it at the same time.

For one, you’ll be surprised how often how you think things are done and how they are actually done are different. It’s something you can only learn by monitoring your current process first before redesigning it.

Start as small as possible.

If you’re introducing an entirely new process, start with something simple. You’ll spend less time monitoring it and it will be adopted quicker. Simple processes are also easier to learn from, because they are easier to analyse.

Figure out where you want to go.

Define parameters of your new process — why you need it, what your desired outcome looks like and what your success criteria are.

Do your research and document your findings, but don’t spend too much time on implementation details. Always favour action over excessive planning when the cost of failure and course correction is low.

Apply small changes until you get there.

Now that you know what your current process looks like, and where you want to go with it, start by applying small incremental changes and measure what impact they have.

Keep your momentum.

Small iterative changes add up very quickly. Think of it like you do of compound interest. If you keep making small changes every week, after a year you’ll be farther away than you think.

Pilot Blog

Start with a Minimum Viable Process was originally published in The Runway on Medium, where people are continuing the conversation by highlighting and responding to this story.