Product process

How we prioritize new features:

1. We’re looking for features that will help our customers make more sales.

2. They will be useful for the majority of our users.

3. They will be useful long term, e.g. it’s not a tool to spam craigslist with a short life span.

4. They have been requested by users and people are actively doing the activity now (there are some exceptions to this rule). e.g. we aren’t going to build a twitter auto poster as 99% of our users never post to Twitter and for the people that are power users of social media already have great apps for Twitter

5. They fit our vision for the product.

6. Many data points over time e.g. user interviews, amount of requests we’ve had, impact of feature on results. e.g. we aren’t jumping onto the newest idea all the time.

We are actively looking for things that will improve our customers sales process 10x over small improvements. e.g. emailing 50 people at once will be much more useful than being able to add attachments to emails (both will be useful, the first one is more useful though).

Generating ideas is easy, the key thing here is prioritization, whenever we work on something that means we are not working on something else.

The best way to provide product feedback is either through intercom inside our app, emailing us directly or on the phone with us. Include what your trying to do, why its important to your business, how you currently do it.

1 on 1 feedback is valuable, group feedback is an echo chamber.

Development process:

1. Understanding what to build

2. Mockups and research of possible solutions

3. Send mockups to designer

4. Weekly sprint process

5. Customer feedback

We have an agile development process with weekly sprints as this reduces a lot of the risk in building complex software systems. As we can evaluate and test the new features added each week. Even if we are building a complex feature that may take multiple months we break it down into weekly chunks.

Promises

We don’t promise features ahead of time or provide ETA’s as mentioned above we use a weekly sprint process this provides us maximum flexibility to improve the product.

Sometimes we will learn things and change direction, which is why we don’t announce features ahead of time as if we’ve announced we will do X we will be more locked into doing it, even if we later discover its not the best thing for us or our customers. David from 37 signals talks about the downsides of software promises here. TLDR anyone can promise anything with little effort.

This process is always changing as we’re hiring more people, learning new things and always looking for better ways to improve the product faster.