Even before I had a true MVP in place, I started reaching out to customers. I felt that waiting too long to reach out and get immediate feedback on product direction from potential customers would be a mistake. With my other product (WorkDive), I did the opposite and learned from it. I simply built the product, pretending that the universe needed it. Looking back, there were well-established products in the time entry space and although I learned from the process, I was building a product that no one really needed at the end of the day. Sure, I had a differentiating angle with SMS time entry, but at the end of the day it would be a dog fight to get users to switch their time entry system to something nascent like WorkDive. It would have been a tough battle and I knew I should move on.
Product development on Staff Mapper started in July of 2017, and interestingly my first email outreach to my professional network about the product also began around that time. While I had just the beginnings of an actual product, I knew that I wanted my customers to drive the product development roadmap, so I started talking to dozens of consultancies, hoping to achieve 1) understanding of needs 2) and early customers.
I spoke with mostly professional service firms, consultancies and other firms who relied on labor as a means to revenue. This was the hardest part of the product development process in my opinon. I had many ideas about what the product was and what I thought it should be. After talking with so many people, I realized that people managemnt is hard - the needs are so diversified and unique.
Here are some things I heard while pitching the product:
“I’d prefer something we can visualize and manipulate in salesforce. I don’t want a stand alone tool, I want to use the tools we have now.” – CEO of a Salesforce consulting company
“Our staff are organized by several small agile teams, so there’s no need” – Manager at a Fair Market Value company
“We just implemented an in-house solution for the entire company” –Consultant at E&Y
“We thought you were a floor planning product” – some random contact who reached out to me about the procuct, referring to StaffMap.com
“We could use the tool as a waste management company to help us coordinate waste pickup at labs all across the northeast” –manager of a waste management company
“We’re using salesforce” – consultant
“We could use it, but were a team of 5” – consultant
“Our culture is not interested in big brother monitoring” –consultant
“The partners here would prefer to retain control over their individual staff” – consultant
“We need to move quickly, decided to go with Everhour” – consultant of a long-term client
“We are certainly at a point where staffing has become a burdensome process. There is a subcommittee of us, of which I am a part, that’s trying to streamline it. Let me know if there is something I can look over, or if you want to set up a call. Certainly looking for practical solutions.” – Partner at consulting firm, eventually become our first customer
BAM! After more than a few conversations, I finally had a warm lead. As you can see, I had a few difficult conversations. I was glad that I hadn’t invested all this time into building a product before I had these conversations. Here’s what I learned about the product needs:
The product should be flexible enough to accomodate for varying cultures at these firms
The product value proposition was not clear enough (e.g. StaffMap.com and Waste Management Pickup Logistics was a fundamental misunderstanding of our objectives)
Some kind of integration was important to some of our customers.
Needs are vastly different at each firm
This really wasn’t going to be easy, but I thought, let me figure out what this one interested client needs and we can go from there. After an initial demo with the partner, he offered up a broader discussion with the rest of the partners. I was suprised - I thought the buyer would be someone in Human Resources. Turns out that the c-suite / partners at consultancies will always be the buyer - they are the most interested in increasing efficiencies, recouping potential lost consultant time and reducing burn out while maintaining culture. My pitch to them was simple:
“If you can recoup an hour of a consutant’s time, the solution pays for itself”.
That was the pitch. Full stop. And frankley, our tool enabled that with ease. Later on, I heard that the demo was was well recieved - they wanted to move forward! BUT they wanted to see a few things in place first.
So I built some of the main features that are still in place today:
Desktop tool to broadcast staff availability, utilization (e.g. how busy a consultant is on billable projects), PTO, both in the short-term and in the long-term.
Long-term calendar view of staff availability
Projections of staff availability and ability to help with a project given current restraints
Ability to claim a consultant’s time with the click of a button (this allowed us to track ROI to our consultant)
Some simple reporting metrics
Ability to add their staff roster and ability for staff to upload skill sets
These were the main features that was just enough for the client to pull the trigger on a monthly subscription at $6/user/month on a trial basis - this means that they loaded a few test users and evaluated how the system worked for them. It was a great way for them to gain comfort with the system and for us to work out the kinks with a live client.
We handled and still handle payments through Stripe, which reads the number of active staff they have in the solution and bills them monthly accounting for fluctations in the staff count over the course of the month. The first invoice for $208 went out on June 6, 2018 after about a year of development and the first pitch.
A YEAR’S WORTH OF WORK. More on this soon.