Exact process for managing product development at NinjaOutreach

Product development is hairy business. You read a lot about growth, but part of growth is developing and designing a great product, and to be honest, there doesn’t seem to be nearly as much written about this process, despite the fact that it is extremely important.

For example, a recent article on Profit Well found that

Improving retention or monetization has 2-4x the impact of acquisition on growth Click To Tweet

And when it comes to retention in the SaaS market, it’s heavily tied to product. Product = Growth.

When I read Oscar’s write up for how they manage their marketing and growth, it inspired me to write the corollary of how we manage product development at NinjaOutreach, our blogger outreach software.

Now, typically before you get into a discussion about features, you have things like the product roadmap, the vision, the market’s needs, but for the sake of brevity (and the fact that it is difficult to distill that into a process), we’re going to approach this with the following 3 assumptions:

  • You have a software application.
  • You have some active users.
  • The next steps for the product are non-obvious.

So let’s begin with the birth of new features.

Where do features come from?

In our case, features inevitably come from 2 sources:

  • Our own ideas
  • Customer feedback

Each has very different motivations, so let’s discuss them separately.

Our own ideas

Although the traditional lean startup approach recommends iterating on what people are asking for, I feel there is room to explore your own ideas as well.

The fact is, many customers don’t know exactly what they want and need, and certainly are not aware of the full universe of ideas and possibilities like you are.

Many customers don’t know exactly what they want and need nor are aware of the possibilities Click To Tweet.
Customers ask for features that they’ve seen elsewhere, but they rarely think about what could be, and these “could be” features are what inevitably make your product unique.

Therefore, it’s worth it to occasionally explore your own ideas, even if they haven’t been directly asked for.

What’s important, however, is not just to come out with crazy ideas for the sake of it, but for these ideas to serve a purpose.

For example, are you trying to reduce churn, and therefore you want to come out with a feature that is engaging and sticky and likely to be a central part of the customer’s long-term usage of the product?

Or are you trying to increase trial-to-paid conversions, and therefore should be focusing on early activation stages?

To put that into more context in our tool, if we’re trying to focus on trial-to-paid conversions, I am likely focusing on features that will improve the prospecting for the user, because prospecting is what users do first, and improving that experience is what is going to nudge them along to eventually becoming a customer.

However, if I want to make the product stickier, I am thinking about the features that will keep them coming back week after week. People don’t really come back week after week to prospect (there’s a limit to how many people you need to find), but they do come back week after week to do outreach – to send new messages and follow up on old correspondences.

Therefore when it comes to your own ideas, I tie them very closely to the Key Performance Indicators that you’re trying to improve.

Customer feedback

The second area is customer feedback, which offers its own set of challenges.

While some customers are very vocal, most are not and leave you hanging wondering what exactly it is that they want.

As a result, we’ve grown to understand the different ways we can solicit feedback from customers without hassling them all the time. Here are some of the popular ways in which we do so.

Ways To Solicit Customer Feedback

Behaviorally triggered messages: The biggest one is in-app messages, which we do through intercom.io. We ask our customers for feature recommendations at 2 stages.

The first is 7 days into the trial, which serves 2 purposes.

Firstly, it gets us feedback early on. Weeks later as someone has progressed into the product, they’ve forgotten about what it was like to be 7 days into it and completely lost. Additionally, most people are still using the software 7 days into it, so it has a large pool to draw from.

Secondly, it functions as customer support. Quite often people request features that we actually have, so asking them at around 7 days gives us an opportunity to point them in the right direction.

Customer Feedback

The second message comes out around 45 days, which serves a different need than the first message. These people have gotten over the initial activation hump and can provide insight into what they really need to get long-term value out of the software. Additionally, these people are often fully utilizing the software, and therefore have a great bird’s eye view of what is really needed and where the real pain points are.

image 2
These are without a doubt our core methods for extracting customer feedback, however, in addition to that, we also have:
Customer calls – These are typically 30 minute onboarding meetings where we talk with customers and get them up to speed and help them with their campaign.

Cancellation surveys – These surveys are mandatory when you cancel. Although you can type in gibberish, many people say at least something worthwhile that can lend itself to a new feature idea.Churn

The Bucketing System

So now you have your feature suggestions – how do you organize them?

We like to use Trello for a bucketing system. This is what it looks like:

Trello Board New

We borrowed significantly from Groove on how to release a new feature and adapted it to fit our own needs.

We have 4 buckets:

  • Our Own Ideas
  • Small Features – less than 4 hours
  • Medium Features – 2-3 days
  • Large Features – > 3 days

As a customer requests new features, we look to see if it already exists, and we append those requests to existing cards (or new cards when they’re created). This gives us insight into how many people are requesting a feature. As more people request it, we move it up, essentially prioritizing it higher. Finally, when the feature is released, we have a group of people whom we can reach out to and notify.

Interpreting The Customer’s Needs

One of the most difficult aspects of product development is interpreting what the customer actually needs.

Here’s an example:
ConfusionThe customer has asked for spin tags. What he means is that he wants to have variation within a template, for example {hi, hey, hello}, and perhaps with some randomness the software will choose the intro for him.

Is that what he really wants though? No, I don’t think so.

What he really wants is better email deliverability and perhaps increased protection that his email account is not flagged as spam.

He believes if the templates are varied that they will less likely be flagged as spam, and honestly that may be true, but is it the BEST way to ensure deliverability and spam protection?

I don’t know, to be honest, but I doubt it.

There are probably many things we could do to improve the deliverability of an email; his suggestion is just one, and it may not be the best or easiest. There also may be other customers who are in essence attempting to express the same opinion but doing so through a different feature, and we should try to group these together to understand if a problem is more widespread than it appears.

UI/UX Design

Once a feature has been categorized, interpreted and selected for development, it’s handed over to the UI/UX designer.

Now, if it’s a simple feature that is very intuitive, we might skip this phase.

However if there are any complexities whatsoever, we want our designer to consider how it will look in the software.

He uses a software called UX Pin to basically design an interactive mockup of what the feature could look like, such as the email finder feature we just released:


This is great because it leaves less ambiguity up to the developer to have to make design decisions.


It’s at this point that many startups might choose to go back to the customer and get feedback on the design, and ask, “Is this what you are looking for?”

And perhaps if it was a REALLY monstrous feature we would do that, but otherwise we skip it and prefer to be more agile. Soliciting customer feedback takes a long time and can add weeks to the development. I just don’t find it to be very practical.

But, if I know I have a few weeks before the feature will get started, I might ask a high valued customer what he thinks, and often the insight is very poignant.

Assigning To A Particular Developer

Once it’s been designed, we have to assign it to a particular developer. For our team, developers should be versed in the entirety of the software, but they do have roles in which they specialize.

For example, one developer specializes in our payment processing, so anything related to Stripe and user registration goes his way. Another specializes in outreach features, because he is familiar with Gmail’s API, and another in prospecting.

So although there are exceptions, it is traditionally clear which feature will go to whom.

Bug Testing And Ongoing Measurement

After the feature is developed, it is pushed to a staging area that only admins have access to on which we can test the new feature and see if it breaks any existing functions. Currently, all tests are done manually, although I have heard that there are automated ways to test for breakage and conflicts – we just haven’t gotten around to it yet.

Once it passes all tests, it is pushed live to our users.

Depending on the size of the feature, we may attach an event to it. For example, when anyone uses the Email Finder feature that was just released, it will show up in Intercom and Mixpanel. This allows us to track usage over time.

Next Steps

If you’re flying by the seat of your pants with your product – stop.

If you’re not taking into consideration customer feedback – start.

If you don’t have a process in place for prioritizing and managing product and development – consider what I’ve proposed above.

I’m all for growth hacking and customer acquisition, but sometimes there are gains to be had in unsuspecting places. Start thinking about product development as a form of marketing and approach it with the same rigor and testing.


David Schneider is the cofounder of Ninja Outreach, an innovative new Blogger Outreach software for marketers. He writes about business and entrepreneurship at SelfMadeBusinessman, and enjoys travel.

WordPress problems?

Our WordPress experts have you covered.

Hyper-responsive 24/7/365 WordPress support, maintenance and small fixes.