At the end of the day, if you’re hiring the right people, they’ll get the work done.

Don’t be a babysitter, be a manager.

“[if] you can’t let your employees work from home out of fear they’ll slack off without your supervision, you’re a babysitter, not a manager.” ― Jason Fried, Remote: Office Not Required

Where to find distributed workers

Deciding you want a distributed team is the easy part. Building the right team is hard and takes time.

Conveniently enough, there are a number of remote and distributed team hiring websites. They are all offshoots of the original that was setup after Basecamp wrote their personal stories of remote work in “Remote” (a great read if you’re new to the distributed/remote team world).

We’ve done the legwork for you. Here are a few of the best sites to find & hire remote workers:

• We Work Remotely – The original remote job board
• Remote OK – Remote job aggregator
• Remote Year – Hire people remotely for a year
• Nomad List – Where remote workers discuss where they’re working

Taking it a step further, find people who are actively engaged in the niche community your startup is involved in. It’s how I got hired (via a blog post and Twitter interaction, from Europe to Australia!).

“Hard work increases the probability of serendipity.” ― Ken Poirot

The qualities to look for in distributed teams

Once you start looking for the right people, how do you know who’s the best fit for your company?

The Buffer team nails it, describing their key indicator for a great distributed team hire being previous experience as:

• A freelancer, or …
• In a startup

We’ve found a few other attributes that can make a great distributed team hire (most are part of our company culture):

• Autonomy
• Transparency
• Communication
• Focus
• Empathy
• Humility

What does it all mean?

Since you might not see your team or be in the same timezone, it’s critical that your work is transparent. So while you’re sleeping, a team member can take over your work, and vice versa.

Instant messaging tool integrations with your project management tool help a lot.

The added benefit of this shift in timezone is it’s easier to focus. Because you communicate asynchronously, it’s more difficult to get interrupted.

But… there’s a dark side to this.

Don’t cave into multitasking 10 things at once. You’ll quickly find that you’ll get less done. But, don’t fret! You can counter multitasking with work-in-progress limits.

It’s all about balance in distributed teams. You’ll even find that being a distributed team will help increase your software quality.

The tools to manage distributed teams

In distributed teams, communication is king.

Because of this, communication tools can help make or break your effectiveness as a distributed team.

Here’s our own distributed team stack to get you kickstarted (most tools are free):

• Blossom – agile project management
• Slack – instant messenger that’s also a notification hub
• Intercom – customer support
• Github – source code management
• Google Drive – docs, spreadsheets, forms and more.
• Skype / Google Hangouts – calls and video chats
• Sunrise – multi-platform calendar app
• Mailchimp – emails and drip campaigns
• Kiwi for Gmail – desktop Gmail support
• Homeslice – timezone syncing

Start distributing… now!

The best time to become a distributed team is now.

If you’re a co-located team, you can trial it out for a few days a week until everyone is comfortable. With the increased work life balance, we have a feeling you won’t go back.

And if you’re starting from scratch, go to the places distributed workers are already at and be deeply involved in your niche’s community.

You never know, your next best hire could be a tweet away.

The post How To Find & Build Distributed Teams appeared first on Blossom.

Building on assumptions

Pretend you’ve just delivered another software project on time and budget. But, there’s one problem: no one is using it. What do you do?

You’d probably think back to when the project started and wish you asked yourself this question:

“What’s the point of developing something really well, if no one uses it?”

If no one is using your product, it’s sitting in one of two camps:

1. Your product is great, but you’re having issues with distribution.
2. Your product isn’t great, and you’re finding that out for the first time.

Sound familiar?

It’s common for teams to initially focus on shipping software faster when becoming ‘agile’.

While this is a critical part of being ‘agile’, it’s only effective when you:

“Make something people want” — Paul Graham

How do you know what your customers want?

Well, at first you don’t. And then you do. And then you don’t again. Then you kind of do.

It’s an iterative process.

At the birth of a startup, this process is called finding your product/market fit.

I think a better way of describing it would be the pursuit of product/market fit.

Pursuing Product/Market Fit

As Sean Ellis sees it, finding your product/market fit is the first of three pivotal phases most startups follow.

Sean Ellis on The Startup Pyramid

The market you target is critical, because:

1. You change your product according to your market.
2. Your market determines how big your startup can become.

If you target a market too small, you can’t grow your product big enough to “make a dent in the universe”. And if it’s too large, you’ll be up against huge competition.

“Product/market fit” can’t be achieved. It’s something you continually optimize and heavily depends on your market.

What’s my market?

Your market is:

Market = ƒ(Jobs to be Done)

That is, your market is the jobs your potential customers want to complete (their jobs to be done). Going deeper, it’s the situations and motivations that lead your potential customers to want to do these jobs.

There’s a number of ways you can better understand your customers (and therefore, your market):

• Show people a prototype of a feature
• Ship a Minimum Marketable Feature (MMF) and measure its performance
• Interview potential customers
• Find potential customer pain points in niche online forums
• See what people are asking for / answering on Quora
• and, so on.

The more context you gather from the above, the easier it is to define the jobs to be done for your market.

After that, you can begin to create a number of solutions (usually, in the form of user stories) to solve your customers goals (i.e. their jobs to be done).

Being lean

Knowing what people want to do is one thing. Turning it into a software solution is an entirely different problem.

The problem lies with being lean.

If you had unlimited resources and time, you could try everything until you find what works best.

Unfortunately, no one has that kind of runway (well, most people).

The best way to find out what to build (and what not to build) is to validate your assumptions and ideas as fast as possible

Prioritize, prioritize, prioritize!

If you’ve correctly identified your market and what jobs they would like to do, you can now build these out as solutions and get feedback on how to improve them.

How do we build these solutions? Job stories and user stories.

For each job your customer would like to complete (define these as job stories), create a number of solutions that can fulfil them (as user stories).

Any one problem can have multiple solutions. Your job is to find the most effective solutions, and to implement these.

If you build these features with a Minimum Viable Product (MVP) mindset, you’ll find that you can dump or improve your ideas faster than ever.

• If you waste time, at least it was a short amount.
• If it was a great idea, you’ll be able to double down on it faster.

It’s up to you

This is how you be agile. It really is a mindset and not a set of tools.

Continually optimize your product’s fit in the market by minimizing wasted resources, through a focus on experimentation over making assumptions.

The post What is Agile? The Pursuit of Product/Market Fit appeared first on Blossom.

It’s the question that most teams want to crack – “How do we respond to change in an ‘agile’ way?”. Automation, and lots of it.

In a global market, it’s critical that you’re able to  quickly ship software changes to your product. Not only do will competitors do the same, but what your customers want six months from now can be very different to what they want today. Using your customers’ feedback (along with old fashion research) enables your teams to build software that will be actually used.

Let’s face it, without feedback, you’re just taking guesses and assuming your customers want these guesses.

Technically enabling your team to ship software fast is where Continuous Integration, Delivery and Deployment come into play. These practices will automate everything from testing to software releases.

Continuous Integration

“Being agile” is a mindset. It prioritizes testing and iteration over assumptions.

So if you can test and ship code faster, you’ll receive feedback quicker and, as a result, make more efficient product decisions. All in all, it means less waste.

To do this in practice, you:

• Ship a small, but workable, version of a feature you believe your customers will use (after asking them and conducting initial research).
• Calculate the feature’s usage metrics, and the like, so you can decide whether or not to a) continue developing the feature, b) pivot the idea or c) drop it all together.

What’s the first key to quicker feedback? Automated testing with Continuous Integration.

Continuous integration is:

“a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible” — Martin Fowler

To get Continuous Integration to work, there are a few basic steps which involve developers committing code to a source code repository which is then tested, integrated and built by a continuous integration server.

When your product is continually being tested, you can feel comfortable with releasing software more often. To boot, you’ll take your test suite completion time down from days to minutes.

Here are some Continuous Integration tools to get you kickstarted:

• Codeship
• CircleCI
• Travis CI

Continuous Delivery

Testing is essential for any software product, but getting the product into customers hands is when the real magic happens.

Continuous delivery is when “software can be released to production at any time”. The ‘can be’ refers to still needing to “push a button” (or run a script) to release the software.

By Yassal Sundman from Crisp’s Blog

This results in three benefits:

1. The team can control when software is shipped, at the push of a button.
2. There are no software release headaches, since releases are now automated.
3. Teams can receive feedback from customers significantly faster.

For continuous delivery to work, a script must be written by the development team to automate the deployment process. In a nutshell, this deploys the latest successful continuous integration build of your software to your customers.

Many companies are now taking this to the next level, and automating the push of the deployment button. But should you?

Continuous Deployment

Continuous deployment  does not require the push of a button to release software. Instead, code is deployed to production (and is “live”) automatically after it is successfully tested and integrated.

Theoretically, it’s not much more effort to skip continuous delivery entirely and go straight to continuous deployment. But, it’s not always ideal to automatically deploy code once developers commit their code.

Here are some situations of when it’s okay and not okay to continuously deploy code:

• Okay – UI changes
• Okay – Fixing small bugs (“Little changes [will only create] little problems“)
• Okay – Adding independent features
• Not okay – Changing critical systems (e.g. payment processing, order fulfilment)
• Not okay – Changing core functionality (some users may prefer the old feature, so this depends more on the product, for example, this is not okay for an accounting system, but perfectly fine for Facebook).

While Continuous Deployment is inherently suited to SaaS companies (people access the product via the Internet), both Google Chrome (installed software) and Tesla Motors (car firmware) have made it work in their less traditional situations.

For some inspiration, here’s a bigger list of successful continuous deployment adoption stories:

• IMVU, since 2009 (50 deployments/day)
• Wealthfront, since 2010
• Etsy, since 2010
• DISQUS, since 2011
• Box, since 2013
• Hubspot, since 2013 (300 deployments/day)
• Tesla and Adobe
• and many more…

What now?

Master continuous integration, delivery and deployment to get feedback faster from your customers. This will enable your team to develop valuable features whilst helping minimize wasted resources and time.

In the next article, we’ll look at how to design features with an ‘agile mindset’.

Read on for Part 3 of What is Agile? – The Pursuit of Product/Market Fit.

Sign up to get notified about future articles!

The post What is Agile? The Developer Practices appeared first on Blossom.

“Growth Hacking” has become a buzzword in the startup world. All startups want to grow, because “Everything else… follows from growth“. And Growth hacking helps startups achieve growth.

So what’s growth hacking?

Growth hacking is the tools, tactics and strategies employed to incrementally grow a startup at scale. It’s not about having one big “eureka” moment. It’s about systematic (and scalable) product growth. And it can be entirely free. It simply requires two things: effort and a bit of ingenuity. This is a far cry from traditionally marketing, and even traditional digital marketing, which have historically relied on advertising funding and marketing budgets.

There are countless examples of companies growing at scale:

• Paypal’s friend referral bounty
• The Hotmail tagline – “Get Your Free Email at Hotmail”
• Airbnb’s craigslist integration
• and more…

It’s important to remember, growth hacking isn’t so much about hacking, as it is about growth.

Who performs these “growth hacks” in a startup?

Growth hackers, of course. It’s an advantage if the whole company thinks in this mindset, but it helps to have a dedicated person responsible for growing your product

Depending on who you ask and how a company is running, the growth hacker role can wildly vary. Definitions range from “a hybrid of marketer and coder” (Andrew Chen) to “someone who has thrown out the playbook of traditional marketing and replaced it with only what is testable, trackable, and scalable” (Ryan Holiday). Whatever the definition, the goal of a growth hacker is to grow their product at scale.

Now that you’re up to speed, take a read of these quotes from the most influential growth hackers to inspire your startup’s growth journey.

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

Tweet this

If you know any other inspiring quotes on growth hacking, I’d love to add them to the collection. Let me know here (@gclaps) or in the comments below.

The post What is Growth Hacking? appeared first on Blossom.

“The single biggest problem in communication is the illusion that it has taken place.” — George Bernard Shaw

We use Slack to communicate between team members, but, more importantly, to be aware of what our team is doing. We’ve connected Slack to our agile project management tool, Blossom, and this is how we work.

Slack moves your project with you

We don’t have to keep our agile project management tool open all day. It doesn’t have to be pinned in our browser. And it doesn’t have to be refreshed every 15 minutes.

When something happens, a message shoots through to Slack – blockers, new comments, task assignments, board updates and more.

It’ll go straight to our mobile, desktop, laptop or even smart watch.

We can then action anything relevant to us. It’s also a neat way to stay informed of what happened throughout the day.

Perfect for distributed teams

This is especially useful when working with team members across timezones. They don’t have to write an email about what they’ve done. And you don’t have to check every card in your project management tool to understand what’s happening in your team.

All the information is there for you to access, right in your Slack message history.

One channel, one board

To keep the noise/relevance ratio low, we create a channel for each project board we’re working on.

If you’re not working on a particular project, this means that you can still see how the project is going, but in your own time. This minimizes irrelevant information flooding your space and maintains the accessibility of project/organization information.

Messages for you and for all

If you’re scared that you’ll be drowning in message notifications, don’t worry. Slack has got you covered.

You can get Slack to notify you when specific words are mentioned.

Or decide which notifications (and more!) get into Slack to begin with, from within Blossom itself.

So what are you waiting for?

If you want to start painlessly and easily managing projects, start communicating with Slack. And if you can, integrate it with your current project workflow.

You’ll never go back.

The post How to manage Projects using Slack appeared first on Blossom.

And now we’re sharing it. Enjoy!

Old School Thought – “Waterfall”

First, some history.

Most software projects used to be run as a series of sequential phases or steps. Something along the lines of:

“Waterfall model” by Peter Kemp / Paul Smith. Licensed under CC BY 3.0 via Wikimedia Commons

It’s what you learn at high school, and it’s what most large organizations still practice.

The (not-so) hidden downside is that it’s sequential. If a requirement is no longer valid during the testing phase or the market has changed, it’s too late. It’s being tested now. Development and requirements are done.

In our hyper-evolving world, this doesn’t quite work in practice anymore. Well, for building great products at least.

They call this approach “waterfall”. Once you go past a phase, you can’t climb back up. It’s a waterfall after all.

As luck would have it, it’s not all bad news.

The waterfall approach suits projects that have requirements which are set in stone. If the requirements don’t change and the rest of the phases are completed at a high quality, you can pack your bags and go home. The project was successful.

But…

In reality, the majority of projects and products are not like this. The market you compete in can change daily and customer feedback can mean your initial idea needs to pivot half way through implementation. At the end of the day, you’re building something for someone. Consequently, their opinions are pretty important.

New School Thinking – ‘Agile’

So a bunch of people got together in 2001 and decided to create a medicine to remedy the immobility present in the software development practices at the time. They called it The Agile Manifesto.

The manifesto consists of a number of values and principles. In a nutshell, it’s based on quickly and iteratively developing software, with a focus on customer feedback and effective communication between the people that build the software product.

Out of this manifesto spun the concept of Agile Software Development, which is a number of methods that can be used to develop software based off the values and principles in The Agile Manifesto.

Alone, Agile Software Development doesn’t do much for teams. It’s the agile software methods that provide teams structure on how to manage and build products. What these methods have in common is that they help teams to build and release software in small, frequent iterations, as opposed to taking the ‘big bang’ waterfall approach of releasing software after everything else has been completed.

Adapted from Ifran Ebrahim

Some of these methods include:

• Scrum
• Kanban
• Lean software development
• Extreme Programming (XP)
• Lean Startup (kind of)

It’s important to note that the word ‘agile’ means nothing on its own. Oxford defines it as:

“Able to move quickly and easily.”

See. Nothing to do with software development.

Agile is a mindset

In the software world (and most other industries), being ‘agile’ is a mindset. Practicing some of the above agile methods doesn’t exactly mean that a team is adopting an ‘agile’ mindset. They provide structure to help you be ‘agile’, but the operative word here really is ‘help’.

What is an ‘agile’ mindset, you might ask? Essentially, it’s mostly what’s in The Agile Manifesto. Practically speaking, it’s about hypothesizing ideas, quickly building them, testing them against real customers and then iterating upon them.

Being ‘agile’ is not something that’s exclusive to the software industry, but it has definitely been popularized by it. Recently, there has been quite a buzz around Agile Marketing. And some agile methods themselves are inspired by other industries (the best example being lean manufacturing and the Toyota Production System).

The Evolution of ‘Agile’

Now the funny thing is that out of Agile Software Development and its methods spun another industry:

Agile consultancy.

And it’s mainly for the Scrum framework. This has (ironically) split the co-founders of Scrum into two separate organizations which provide separate Scrum certifications (Scrum.org and the Scrum Alliance).

Because of Scrum’s widespread popularity, many people have begun to confuse Scrum with agile (and ‘agile’ with agile software development, just to add to the confusion). As you can tell, it all gets a bit messy from there.

It’s All About Context

To boot, some of The Agile Manifesto values have been taken out of context. For example, the following value has been taken by countless teams to mean that near-to-no documentation is part of being ‘agile’:

“Working software over comprehensive documentation”

The reality is far from this…

All in all, agile software development has enabled the software development industry to progress. It helps teams build higher quality products in shorter time, which means less waste. Innovation is faster and humanity benefits.

There are many more intricacies that have lead to the rise of Agile Software Development. They are mostly technical, but at core, are industry-wide mindset changes. We’ll describe these in Part 2 of Agile 101.

Until then, keep iterating!

Read on for part 2 and part 3 of the What is Agile? series.

Recommended Reading

Beginners articles:

• New to Agile and Scrum
• Agile Vs. Lean: Yeah Yeah, What’s the Difference?
• Agile Practices: Reference Guide

Advanced articles:

• Flaws In Scrum And Agile
• Agile Versus Lean
• The New Methodology
• From Scrum to Lean

Sign up to get notified about future articles!

The post What is Agile? A History Lesson appeared first on Blossom.

Sell your Story, not your Product

A story is always easier to remember, especially in comparison to just mentioning the name of a product. Telling your personal story and why you are building a specific product is something your customers can relate and connect to.

People don’t buy what you do; they buy why you do it.

— Simon Sinek

A story lets your customers truly imagine your point of view and the features you implemented, in your product, start to make sense to them. A good story will stick to your audience and people will start telling it to others. Read more on storytelling methods in this great article.

Concrete & Emotional beats Abstract & Intellectual

Explaining something in great detail to somebody who is not familiar with a specific topic can sound very abstract to the listener. It’s quite clear that being concrete and to the point is better than just beating around the bush. Consciously thinking about how to phrase something short but precise and understandable for everybody is often a challenge, but the more and more you pay attention on explaining something concrete it will be an ease to make a habit out of it.

NO HAVE PERSONALITY? PRODUCT BORING, NO ONE WANT.

— Fake Grimlock

Being emotional on top of being concrete shows more personality and gives your customers a sign that you truly care about them. It shows that you are open and honest to them and that you deeply care about what you are working on.

Match the User’s Search Intent with the Results they get delivered

Aligning the expectations of your users and what they get delivered is essential for a great user experience. Clicking on a link with a certain title should guide the user to what the title promised. The result of a Google Search should guide the user to what he searched for.

Write For Intent, Not Keyword

— Nate Dame

For example, if you recognize that your blog article is always found through a different search term than your article title you should think about changing the title to the one people are searching for to match expectation and result.

Evaluate Your Bounce Rates

Bouncing != Bouncing. If you only have a single landing page to browse your product it is quite obvious that the bounce rate will be really high. To get more valuable information about your bounces you can filter the bounces i.e. by setting a timer of 30 seconds. If somebody stays on your site for 30 seconds it is likely that this person is actually interested in your product.

A different or additional way of tracking interest could be how far people are scrolling down on your site. To analyse that behavior you could add event listeners which are triggered if a particular section in your page has been reached.

Check these great sources out to learn more about Growth Hacking:

The Definite Guide to Growth Hacking – A extensive guide with beautiful illustrations to company growth by Neil Patel & Bronson Taylor.

The Ultimate Growth Hacking Sourcebook – An awesome collection of modern Growth Hacking case studies by Tiger Tiger.

10 Effective Growth Hacks to increase your SaaS Revenue –  Every Growth Hack in this post works, even if you haven’t nailed product/market fit yet by Thomas Schranz of Blossom.

Ultimate Growth Hacker Resource List – A huge list of over 300+ books, articles, tools and more to help with everything growth by Autosend.io.

Hackers & Founders TV – Insightful videos on Growth Hacking, I very recommend this source.

SEOmoz Blog – A great source for getting tips on SEO, Online Marketing and Business Development.

Conversion Rate Experts Blog – Hands-on Growth Hacking Tips.

Blind Five Year Old – A blog by an online marketing firm specializing in search, owned by AJ Kohn.

Unbounce Blog – Find input specific on optimizing your landing page, online marketing & conversion rate here.

Growth Engineering 101 – A step by step guide on Growth Hacking for Founders, Product Managers and Marketers, which will be published as a series of ongoing blogposts and as a book.

Defining a Growth Hacker – Great series about the meaning & practical application of a Growth Hacker by Aaron Ginn on Techcrunch.

1000 Grand True Fans – An inspiring article on being aware of each and every of your fans/customers.

Which Growth Hacking Tips would you recommend and which are you applying? I’d love to hear them in the comments.

Receive our articles from business and customer success over to design, engineering & product management right in your email inbox by subscribing here.

The post 4 Essential Tips for Growth Hacking your Startup Mindset appeared first on Blossom.

While the email performed 2x better than our second best email in the campaign, there was a problem with it…

We had a lot of clicks with the call to action, but not as many people followed through with the action itself (i.e. joining the webinar).

Fair call. People might not want to join the webinar after reading its details.

So we decided to change our first onboarding email to one that promotes our awesome support (we use Intercom to chat to our customers in real-time).

And it didn’t work out…

Result: 65% less clicks and 17% less opens.

Holy Guacamole, we screwed up! Right? … Nope. The numbers lie.

Actually, it did work out!

We tripled our monthly revenue in the same time frame as the change.

Say what?!

We started using Intercom to manage our customer support (and put it in our drip campaign, like I mentioned above). And because of it, we had:

• … more people asking us for help
• … provided more consultancy advice
• … spoken directly to more customers in real-time

Not everything that can be counted counts.
Not everything that counts can be counted.
— William Bruce Cameron

Our customers’ success turned into our success. Woo!

Numbers can lie

Lesson learnt: Don’t judge an email by its click through rate.

We have learnt to focus on overarching drip campaign goals (e.g. increase in revenue). A call to action button might not lead to an action beyond the initial click.

And most importantly, customers are the core to your business, so make them as awesome as you can. It will always pay off. Period.

Remember, positive email metrics can lie.

Let us know if you’ve had similar stories – we’d love to hear them!

The post Why You Shouldn’t Rely On Positive Email Metrics appeared first on Blossom.

The first few times I got these questions my reply was a blank stare.
I even felt bad about not having an answer.

By now I take the question as an opportunity to explain what I think about our market, our competition, where the whole software industry is going and why I’m excited about the space we’re in.

To be honest I’m fuelled by this crazy feeling that I have. Profound fear.
I’m scared that if we don’t do the things we do at Blossom no one else will.

For me building a company is about shaping your own and everyone else’s destiny.
Instead of complaining about the status quo and hoping someone listens we are shaping how the future of software development looks like. That’s just much more fun.

“The best way to predict the future is to invent it”
— Alan Kay

It’s ok to not have an exit strategy.

I’m glad we’re not the only ones who think like that. Phil Libin of Evernote has a great related Stanford talk about this: “No Exit Strategy for Your Life’s Work”.

Next time someone asks you whom you want to get acquired by don’t feel bad about not having an answer. Be bold. Take it as an opportunity to think about whom you’d like to partner with and whom you’d like to acquire.

The post What’s your Exit Strategy? appeared first on Blossom.