Finding Our Product-Market Fit(s), Part II

How we navigated various market opportunities and evolved Philosophie to meet them. Part of the Still A Startup series.

This is the second part to Finding Our Product-Market Fit(s).

In my last post, I talked about one side of the PMF equation: the market. Most startups that I work with start with a product or vision, and then try to find customers who buy into what they are selling. It’s no surprise that this is the typical pattern — it takes a very strong vision to pull an entrepreneur from the comfort of a normal job toward the completely irrational decision to start a company.

In our case, we didn’t have a strong vision. We just had skills that we could sell. When Emerson and I started, our purpose (if you could call it that) was to team up and build cool stuff. Not the strongest mission statement, but hey, we had people who were willing to pay us.

Aside from earning a living and having fun doing it, we hadn’t thought about our “why.” We didn’t even think about our personal preferences, because we didn’t really have any. But after the first few years, substantial growth, and an awful lot of progress, we were starting to have some pretty strong preferences about the type of work that we wanted to do.

Product Pivot #1

As I mentioned in the last post, after launching nearly 100 projects, we started to feel like the way most websites and apps got built was wrong. As the makers behind them, we felt unfulfilled when the big launch that we were working up to was met with deaf ears. Even for the more successful launches, seeing the campaign shut down or huge user drop-off after just a few months was disheartening. We wanted to have more impact with the things we built.

When we asked ourselves, “how do we do that?”, the answer seemed overwhelmingly simple: we needed to change our process so that we could be more agile. Agile methodologies were well-defined and we were very familiar with them. The problem was: how do you sell agile?

Selling Agile

This was something that we struggled with for almost two years. Our agency clients needed fixed-scope, fixed-cost, fixed-timeline contracts, even in 2012. That seemed to be what our small-business customers wanted and corporate customers demanded as well. So we lost some projects to other firms willing to do things the old-fashioned way. But we kept trying, and found some startups that “got it.”

In our first approved “agile” proposal, we focused on several big goals that had emerged from stakeholder interviews during the sales process. We wrote a couple paragraphs about each of them. For a few of them we mentioned specific features, but we used phrases like “possible features” or “we may decide to prioritize.” We were very careful not to commit to a specific scope of work, because we knew that as we went along, user feedback and shifting business priorities would change it anyway.

Instead, we wrote about the skill set we would bring to the table, the project management approach, and a rough timeline that corresponded to the overall budget and the per-sprint fee.

I thought we had cracked the code and finally figured out how to sell agile.

How’d that work out?

Unfortunately, the project was a disaster. The first few weeks were amazing: we let the designated Product Owner drive the priorities, and built a ton of value-adding features that we would have never imagined to put in a fixed-scope proposal. The velocity of the project was extremely high. We felt like we were solving real problems instead of just building to spec. Agile is the answer to everything!

But unfortunately, we were quickly disillusioned. The Product Owner kept prioritizing administrative features and we started falling behind schedule. We saw it coming well ahead of the game, so we went to the CEO to ask for more money. He was not happy. Apparently, he thought the contract he signed was fixed-price. He gave the Product Owner a piece of his mind, and she called me and gave me the worst chewing out of my life.

Our project got killed, the client-side Product Owner was fired, and we gave back the remainder of the client’s deposit, which at the time was a big ding to our cashflow. Worst of all, all of the meaningful software we had developed to-date would never see the light of day. Our first agile experiment had failed.

The next one wasn’t much better. It was a marketing site and onboarding flow for a service that matched real estate buyers and sellers with the best agent. It was an awesome idea, and the company was run by a very talented and creative entrepreneur who was never short on ideas or opinions. The project goal was to increase conversion rates, and the approach that we thought we sold was to test different versions of the page and iterate to see what worked. However, the Product Owner was very focused on first driving a more creative and beautiful UI. We gave in, accepting very detailed feedback and micro-iterations on the UI before ever launching.

As with the first agile project, this one went over budget and past its timeline, and the client was not happy when we asked for more money. And again our initial reaction was confusion: we had worked within the terms of our “agile” contract and done everything the client asked of us, and yet they are still unhappy!

Would it even be possible to practice agile in an agency setting?

Pivot or Perish

Whether you have customers or not, the hardest part about Product-Market Fit is knowing when to change yourself. As cliché as it is:

The definition of insanity is doing the same thing over and over again and expecting different results.

I’ve met hundreds of entrepreneurs who are so committed to their vision that they will push forth relentlessly despite a lack of supporting evidence and even strong contrarian evidence. In fact, I would argue that this behavior is a requisite default state for a founder, because they need the ability to rally people and resources around something imaginary.

As a result, it is very tricky to know whether to “pivot or persevere.”

But the decision becomes a little easier when you have a more flexible definition of yourself. If you define your entire company in terms of a particular product vision, you can’t pivot the product very easily. You can only pivot the market. So if there’s no market, you’re screwed.

Whereas if you define your organization in more abstract ways, you can be more adaptive in finding your path to success. Having a mission statement that is focused on solving a real problem is a wonderful guiding light. You can change your product, competitive strategy, staffing, business model, or just about any other part of your organization if necessary to solve that problem. In other words, the “why” is your constant and you’re unencumbered by the “what” and the “how.”

Some organizations like to also have a set of values, which help inform the way in which they go about achieving their mission. In other words, it puts constraints on the “how.” This is where we found ourselves at this point in our history. We were beginning to articulate and insist on our preferences for how we built products. Our values overlapped a lot with those of the Agile Manifesto. They overlapped with those of Balanced Team. They overlapped with those of Lean Startup. And they overlapped with those of many talented designers and developers who wanted to join our team.

But they didn’t overlap with those of our clients.

From the end of our first year in business to the end of 2012, we had achieved a compound annual growth rate of 163%. In 2013, when we shed our agency partners and exclusively pursued agile work, we grew only 6.6%! This did not feel good considering how much we had invested in our staff, office, and equipment.

Clearly we had a problem with PMF. We had previously found a market, but we weren’t happy delivering the product that it demanded. So we changed the product, and had to again hustle to find a market.

What we learned

It wasn’t 100% clear at the time, but in retrospect I can provide a nice summary of why our first agile product didn’t do well in the market.

Clients don’t care how the sausage gets made. They only care about results. We’ve learned that our clients can appreciate our process and understand it rationally, but at the end of the day, it really doesn’t matter. Whatever their success criteria are, if they are not met at the end of the project, it failed. Now, understanding what those are in measurable terms is the first thing we do on every project.

All projects have budgets, whether we know it or not. Budgets come in all shapes and sizes, but starting an un-scoped project without regard for how much funding has been allocated toward the end result is a recipe for failure. Now, we try to make sure that the real budget and ROI requirements are realistic before our second sales meeting.

If they are hiring an agency, they don’t want or can’t do the work themselves. Agile development requires a lot of participation from stakeholders and subject-matter experts. We also want our clients to be able to sustain products we build with them without relying on us. However, we’ve learned that there’s a limit to the attention that a project gets from its stakeholders, and this can never be an excuse for not succeeding. This is especially true of budgets and timelines.

You have to have a why that both you and your clients can rally around. “We exist to do agile” isn’t a very strong rally cry for attracting and retaining clients. When we started, we had a very loose “what”: we build websites and digital products. Now, we had a pretty narrowly defined “how” in the form of sophisticated design and development methods. But we could barely answer the question, “who cares?”

We needed to step back and address these issues before our next product pivot, the one that put us back on track and helped us better align with our clients’ needs and values.

Stay Tuned

Next time, I’ll talk about how we went deeper to define our “why,” and how it helped us find the right clients and services to provide them with.

Love this post? Like it and follow us!