Posts tagged SaaS

Product Market Fit for Slow Sales Cycles

There are a ton of a articles, books, blogs and postcasts out there detailing when you know you have Product Market Fit. Marc Andreessen is usually credited with coining the original term so I won’t deviate here. Product Market fit is generally accepted as having a product that satisfies the needs of a target market.


So how do you know you have product market fit? Much like everything in the world there are tons of possible and correct answers. But it really does vary with your business, product and market.

I’m going to explain how I see product market fit for my SaaS business, Resgrid, which targets non-profit, volunteer organizations. Which if your trying to sell a reoccurring service to has to be the worst combination of attributes to a quick and efficient sales cycle.

On a Quora Answer Nadim Hossain founder of BrightFunnel notes that the average sales cycle for companies in their network is 112 days. For Resgrid our sales cycle is over double that at 294 days. This is observable from our paying customers from initial account creation (we have free accounts) to first payment or first contact via email. So it takes about a year for our sales cycle to fully complete, this means that evaluating product market fit based on companies falling out of a sales cycle too slow for actionable feedback.

So how is another way we at Resgrid determine if we have product market fit? It’s easy, we talk to potential customers in our target market. We focus on first responders and at the moment we are focused on all volunteer or combination fire, search and rescue and CERT departments. When we talk to those customers and they ask us if our software can meet their needs the more times we can say “Yes” the better our fit is.

Of course we will never be able to say “Yes” to every question, but when we first started out there were far more “No”’s or “We’re working on that in the future”’s then “Yes”’s. So for us, we know when were zero’ing in on product market fit when we honestly say to customers that at the time they ask the question we can fulfill the need.

If you have a faster sales cycle, then using your funnel to determine product market fit is a good way to go, but let that from interacting directly with your potential customers. This of course doesn’t mean were stopping developing or enhancing features. Quite the opposite, we have a very health backlog of features to add and enhance. To full our backlog we taken input from existing customers, potential customers and our own roadmap\experiences.

The one thing we’ve never done to fill our backlog is look at our competitors. Chasing features is a great way to forever stay behind the curve and we at Resgrid want to set the curve and thus solidify our product market fit.

Resgrid is a SaaS product utilizing Microsoft Azure, providing logistics, management and communication tools to first responder organizations like volunteer fire departments, career fire departments, EMS, search and rescue, CERT, public safety, disaster relief organizations, etc. It was founded in late 2012 by myself and Jason Jarrett (staxmanade).

Plan Exit/Migration Strategies for your 3rd Party Integrations

In this highly interconnected world our products or services rarely operate in complete isolation. We rely on 3rd or external parties for services or logic that we’d rather no do ourselves, well at least most of us. When I first started in software development I always did it myself. “My solution will be better, it will be exactly what I need, my implementation will be more flexible, etc, etc, etc” those thoughts would always come up when I needed something outside the domain of what project I was working on.

third_party_systemsNow days, I look for external products or 3rd party solutions that meet the 80% rule. “Will this product/solution meet 80% of my core needs?” If it does, I jump on it. I’d rather spend my time taking the product or service the last 20% (which probably has more value to my business) then coding the entire thing. You might be able to build a better wheel, but should you try? When your trying to build a while new vehicle should you spend your finite amount of time and energy on it.

Because of this my products usually have a good number of external integrations, but that brings risk along with it. What if the service shuts down? The API changes? They pivot into something completely different. What happens when the stop supporting the product or code base? So what do you do? As my friend Dale would say, “That’s an uptown problem” and for the most part I agree with him. You can’t see into the future so how can you really mitigate that risk without waiting a whole lot of time.

Although it is a “Uptown problem” it can very quickly and without notice become a “it’s in your house” problem. As it did for us at Resgrid which is a SaaS deployed on Microsoft Azure, providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in late 2012 by myself and Jason Jarrett (staxmanade).

So what should you do before hand? Here is our list of data you should collect when you intergrade a 3rd party solution into your product.

  • Research alternative services/products and compare contrast it with your current solution. This will help you identify other potential external 3rd party migrations. Keep the list short, at max the top 3 other solutions, but elect the ‘Plan B’ option and have some additional information on it compared to the others.
  • Spend an hour and determine if it could be done “in house” and how much time and effort would be required. Determine the high level work that would need to be done and how it may be composed.
  • Is it possible for your product to work without the service? If so can you turn the feature off easily to hide the issue. Do some brainstorming and have a plan of action if this is the case.

Share your findings with the team to build up some institutional knowledge then store it in a wiki or central documentation location. When you may need this knowledge it could be without notice. For us at Resgrid, we discovered an issue sending SMS gateway email’s to AT&T customers during our standard Friday deployment. Customers not being able to receive text messages from Resgrid is a big deal so we investigated and decided that we needed to implement Twilio. A day latter we had a working solution in production and our AT&T customers hopefully didn’t notice any issues. Because we had been investigating Twilio already we had some institutional knowledge built up and could implement it quickly.

If we didn’t have the knowledge built up, we could have wasted a lot of time researching alternatives, putting hacks in place and possibility making it worse. Just because something may be an “Uptown problem” doesn’t mean you shouldn’t invest some time now to help easy pain in the future.

Forcing yourself to launch your product

So you’ve spent all this time building a product or service, when do you finally launch it for money? This can be one of the more difficult decisions that you have to make. As a developer we are hard wired to be passionate about our craft, especially when it’s our baby. Even the most detached developer gets that glimmer in the eye when it’s about the code they wrote for that critical process. When it’s your own product or service and a direct representation of you sending it out into the wild, and asking money for it, prepare for an internal tug of war like you cannot imagine.


Besides naming your company or product one of the most important emotional decisions that you will have to make is when to launch your startups product and asking people to use it and more importantly pay for it.

Some history, this is from my experiences with Resgrid which is a cloud service company, SaaS deployed on Microsoft Azure, providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in 2012 by myself and Jason Jarrett (staxmanade) and we launched it as a paid product in 2014.

The Resgrid SaaS runs on Microsoft’s Azure and was up there at the end of June 2012. We started charging for the service January 2014. That’s a year and half we had the product up there for free. Even with a year and a half of development and work, asking people to pay for it was a very difficult decision. There was more to add, more to fix, more to test, more to improve. it never ended.

So how can you force yourself to launch your product?

1.) Have a partner/s or a sounding board

Having someone with knowledge of the product or service, with experience in launching or good baseline knowledge I think is important to forcing you to think critically about your baby. An different perspective is incredibly valuable when internally your conflicted about a decision. Even if you don’t want partners in your endeavor then find someone who will listen and give advise. What you don’t want is someone who will blindly agree with you.

2.) Have a MVP spec and stick to it

At some point early in the process determine what your minimum viable product is, what would be the baseline someone would pay for? It can be one feature, or a set of features. But your not talking full on double rainbow, just the bare minimum feature set. Your MVP is important, it’s the baseline of what people will use, find useful and possibly pay for. But it gets it into their hands early. Resgrid launched on 6/22/2012 with a MVP (allow first responder personnel to denote if they are responding or not). Our mobile apps were dead simple:


Oh yea, now that’s an MVP. A lot of what we’ve added to Resgrid over the two years has been feedback from our customers, or as Jeff Atwood would say, Complaint Driven Development. This is something that I pride myself on and as a company Resgrid prides itself on, quickly responding to our customers feedback. But if we didn’t start with an MVP and get it into the hands of our users, we most likely would be a completely different product.

3.) Get rid of friction

Before you launch, get your development and deployment stories sorted. Think of this as softening the beach before the invasion. This gets rid of the excuse of “it’s too time consuming or costly to get it out there” (especially for SaaS products). At Resgrid we use Microsoft’s Azure coupled with BizSpark this lowered our cost and allowed us to iterate very quickly.

Remove all the friction that prevents you from focusing on your product. Use cloud providers, like Azure, to deploy your product to for getting it in front of your customers, even if you eventually expect to house it yourself in house.

4.) It’s good enough

Launching will never be easy, it will never go flawlessly, there will always be problems and people that hate it. That’s just the way it is. We iterated on Resgrid for a year and a half, pushing weekly updates and getting feedback. But it was still a difficult decision. There are still parts of the app that need more QA, more work, help and insight for the users, documentation, etc. But those elements and issues will always be there.

You will never polish every edge case, every combination or usage pattern. Instead of tying to fix all of those, focus on your “Happy Path” and ensure that works well. Then respond to customer feedback and fix the edge cases you didn’t think of or didn’t test.

5.) Set a date and stick to it, no matter what

I’m not a fan of hard dates for delivering features. I feel that this can cause a business to be less nimble in response to issues, customer requests or changing market conditions. But for your launch you need to just set a date and make sure the product is MVP complete about two months before that. Spending the remaining time fine tuning, testing, fixing critical bugs and preparing your marketing collateral.

Don’t neglect your public presence like blogs, twitter, Facebook, public site, etc. Unless you have a built in audience or are well known it can be hard getting the first user, even if the MVP is a free alpha. The goal with your launch is to get users on it as quickly as possible, get feedback and iterate as fast as you can.

Don’t worry about complaints, issues or other negatives

This is going to be tough, and I didn’t put a number on it because it’s not a ‘thing’ to try and get you to launch. No launch goes smooth, there will be issues and probably a lot of your early adopters will probably leave and never come back. Don’t dwell on the negatives, you need to push on and keep iterating.

Launching something is a rollercoaster, from major emotional highs (getting signups, paying customers and compliments) to some serious lows (crashes, unsatisfied customers and no signups). As the adage goes, it’s a marathon not a sprint. Don’t fear the negatives, learn from them and move on.

Go to Top