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).
Today Resgrid is being featured by Microsoft as their featured BizSpark startup. Resgrid is a SaaS product deployed on Microsoft Azure, providing logistics, management and communication 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).
For me this is a big deal. I’m sure Microsoft is getting tons of companies applying to be featured and they picked us, pretty cool. But I’m also excited because Resgrid currently is a very niche service, we are geared toward first responders. Most large companies, VC’s, investors, PR companies, writers, etc all want the consumer product story, the next Facebook or Twitter, startups like us don’t get much love.
Serving first responders is a very unique, challenging and rewarding niche to be in. I’m a volunteer firefighter and EMT and love the fire service. But there aren’t a lot of technology companies out there that serve the fire service or first responders. Sure there are some big guys out there with CAD systems, onboard computers, HUD’s, etc. But these technologies cost millions of dollars to implement, install and maintain.
There aren’t many “Web 2.0” technology companies out there serving this market, especially in countries other then the United States. Resgrid is one of a very small number of vendors serving the non-US markets for first responders. We’ve done this in such a short time span by building our solution in a cloud/Azure first mentality.
This is just the start for Resgrid, we are looking forward to expanding our service to more first responder organizations the world over, ensuing that they all get a great service. We are this far already because of our partnership with Microsoft and the Bizspark program. As we look to the future we are excited with the features and capabilities Microsoft and Azure give us, allowing us to continue to serve our existing customers and grow.
In 2009 Paul Graham posted on his blog about Makers and Managers. I don’t know if he was the first to blog about it but this was the first time I read about it. When I ran across that article in 2010/2011 I really didn’t understand it. I was a full time developer and wantrepreneur so I really didn’t ‘get it’. Fast forward a few years and with a partner Jason Jarrett we launched Resgrid and my perspective changed.
The Maker/Manager issue is about context. A Maker (Developer/Programmer) has a different context then a Manager (Supervisor/Owner/Executive). Context switching is a well known issue for developers, every time you need to thing about something other then what you’re currently working on there is a cost, your brain needs time to adjust, so if you’re constantly switching contexts you will never get in a flow.
In either context (Maker/Manager) you can get into a flow, which is important. Based on our history/skills we will gravitate to one or the other naturally as it’s more comfortable for us. However, this can cause huge issues for startup founders.
When your in Maker mode your looking at features, bugs or whatever and trying to figure out how to do them, which patterns do you use? What architecture would you implement? How is the UI going to look, etc. Your then going to go ahead and implement it.
In the Maker mindset your going to just create and find reasons create. Don’t like that pattern/code refactor it. Oh that feature may be good for 1% of my customers, spend a week implementing it. A Maker’s context is creation and implementation.
In Manager mode, your looking at direction and hopefully utilizing analytics and real paying customers to drive your decisions. You will plan out features, set schedules, work on a budget and gather/document requirements. At the manager level your doing business work, working with customers and growing your business.
In my mind the Manager has much more to juggle, but it’s because I’m far more comfortable being a Maker. Managers don’t handle implementation and will tend to get themselves into analysis paralysis if they aren’t careful. A Managers context is business oriented and the ‘30,000 foot/high level picture view’.
Why set a Schedule?
The issue is that we will all lean toward more one then the other. In my own experience with Resgrid I’ve spent far more time developing then growing the business. Everything I do somehow leads back to more development and more code. As a startup founder you can’t just write code and actually this could be the least valuable thing you do.
So setting a schedule where you will dedicate days to being one or the other will help force yourself to do something your probably not comfortable with. This will help you get into flows and ensure your not letting part of your business stagnate. If your naturally a Manager, maybe your not going to write code on the Maker days, but getting more involved with your product’s guts is important.
Setting the Maker/Manager day doesn’t mean to totally neglect the other. For example of your on a Manager day and the production system has a critical bug you should fix it. But don’t work on feature development don’t develop or write code unless it’s fixing a problem. The same goes for when your in a Maker day, don’t neglect your customers support emails and calls, but don’t work on marketing strategy or budgets.
What am I doing
One of my goals for this year is to get into a Maker/Manager schedule. Monday, Wednesday and Fridays are my Manager day, Tuesday, Thursday and Saturdays are my Maker days. Resgrid deploys every Friday, so part of that day I’ll be in ‘Maker’ mode. Sundays will also be my light/off day I’ll only be working on major issues.
My goal is by Q2 2015 I’ll be fully on this schedule, I’m going to ease into it, due to the amount of work I need to get done on the Maker side.