Tag Archives: startup

4 Key Tips For Attracting A Non-Technical Co-Founder

Recently Michael Hughes of CoFoundersLab wrote a nice piece on how a non-technical founder can attract a technical co-founder. I’ve read many similarly written blogs and presentations. Most all say the same type of thing: build a prototype, learn to write code, talk to customers. So I thought it would be interesting to look at the opposite situation: how can a technical founder attract a non-technical co-founder?

It strikes me that you could take many of Michael’s points and apply them equally to attracting a non-technical co-founder. Especially the ones about focusing on attracting a co-founder as opposed to finding one, getting into the right mind set, and a co-founder wanting to work with you instead of for you.

In fact, you could take many of his sentences and simply turn them back around to a technical founder. For example: “Repeat this to yourself until you believe it in your bones”: your idea isn’t the best idea, and a non-technical co-founder doesn’t want to work for you on simply selling your idea.

I’ve come across too many technical founders who see the problem as simply a question of sales. In their minds, they of course have the most brilliant product idea, and they may even have spent weeks or months building a product with slick features. Now, all they need is a “sales guy”, “marketing guy” or “business guy”, and of course the money will come rolling in.

If the product doesn’t sell, it’s easy for the technical founder to simply blame the sales guy or marketing guy. After all, clearly the product is great, so if it’s not selling it’s obviously sales or marketing’s fault!

Michael rightly says: “You may very well have the next game changing idea, but that’s missing the point.” The missing point in this case for the technical founder is market validation.

With all of the education out there about customer development, talking to customers, “get out of the building”, etc., I still meet many technical founders who are so completely convinced of their product idea, and they’ve spent months and even lots of money to build a product, yet have no proof whatsoever that a single customer would actually be interested in, let alone buy, their product. That’s because they’ve spent zero time in the marketplace actually trying to identify who their target customer may be and whether these customers actually care. Often times their market research has been limited to a few conversations with trusted friends and family, or they rely on broad industry research or market trends. But unless friends and family are your target customers, their opinions, while interesting and ego-flattering, are utterly irrelevant.

Technical founders are sometimes surprised when non-technical co-founders start providing input into the product features. Reality check: if they’re out there talking to prospective customers, they’re absolutely going to come back with input on features and capabilities that they feel need to be developed to satisfy your customers.

So how do you attract a potential co-founder? You can start with these four tips:

1. Make sure you’ve identified a real problem.

An idea is worthless unless you can clearly articulate who is your potential customer and what problem it solves for them. And you need to be able to state the problem from the customer’s point of view.

If a technical co-founder looks to a prototype or code as a form of commitment from a non-technical founder, a non-technical co-founder is looking for work done to obtain actual market validation as a form of commitment from a technical founder. Currency here is in the form of actual customer interviews.

2. Learn to do customer development.

If you want to gain respect from a non-technical co-founder, learn to how to find and interview customers, identify early adopters, understand your market, and get buyers. This will show that you haven’t formed your idea or developed your product simply in your head, but you’ve done so in response to the demands of your market. Nothing is more impressive than being able to clearly articulate who is your early adopter customer, and better yet, show that you have a paying early adopter customer.

3. Start talking about your product in terms of benefits, not features.

When describing their product ideas, many technical founders describe a laundry list of features. While some of your features may actually be pretty cool, the reality is no one actually cares. What customers really care about is how your product solves their problems, and that means being able to communicate in benefits, not features.

If you’ve done #1 and #2, #3 becomes easier to do. If you’re able to speak in terms of benefits, you will demonstrate to a non-technical co-founder a grounded, realistic understanding of your market.

4. Stop saying “There is nothing like this out there” or (worse) “There is no competition.”

Sorry to burst your bubble, but odds are very high your idea is not that unique. Repeat this to yourself: There is always competition for my product.

Keep in mind the competition may not always be another company or product. Your competition may very well be how customers are solving their problem today. A great example is Quicken. One of the biggest competitors Quicken was competing with when it first launched was the paper checkbook and pen. Your biggest competition is often current customer behavior.

Just like Michael says in his article, remember to treat your non-technical partner like a true partner, not just the person who will “get sales”. The key to attracting world talent here is to show commitment to obtaining real, tangible progress in your target market. Best of luck!

Before Product/Market Fit comes Opportunity/Company Fit

In his book, Running Lean, Ash Maurya presents a workflow for taking a product from idea to launch to Product/Market fit.

Ash Maurya workflow
In the Problem/Solution Fit stage, you are trying to answer the question, “Do you have a problem worth solving?” Ash breaks this down further into three questions:

  • Is the problem something customers want solved? (must-have)
  • Can it be solved? (feasibility)
  • Will they pay for it? If not, who will? (viability)

Problem/Solution Fit is pursued by capturing your business model hypothesis and then doing Customer Discovery via problem interviews and solutions interviews with customers. Once you’ve validated from customers that you have a viable problem worth solving, you move into Product/Launch Fit.

In the Product/Launch Fit stage, you are trying to answer the question, “Are you ready to learn from customers?” Key activities pursued here are reducing down your MVP, getting to Release 1.0, defining your key metrics, and continuous deployment. The purpose here is to lay the critical groundwork to maximize speed and learning for future iterations, and to establish “just enough” traction among customers to support learning.

Finally, in pursuing Product/Market Fit you are trying to answer the ultimate question: “Have you built something customers want?” This is where the rubber hits the road, and you’re validating your complete product. Identifying the “right” metric or set of metrics, prioritizing your feature backlog, and ensuring retention and getting paid are critical to the success of achieving product/market fit.

This Lean Startup workflow is one that could be used by a product manager pursuing a new product idea or looking to introduce an existing product into a new market. After all, the product manager in such a situation must be able to answer the same set of questions about who is the customer, what customer problem is the product trying to solve, and will enough customers care enough to pay for the solution. The product manager typically starts with some sort of informed hypotheses to answer these questions, which form the basis of the product vision. And the product manager must stay in close touch with customers to validate whether the product is truly something they want.

I feel there is one critical step missing in this workflow, though. It has to do with the unique situation product managers find themselves in versus entrepreneurs. Whereas an entrepreneur is trying to discover a business model that works, a product manager is typically an employee in an existing company already executing a repeatable and scalable business model. As such, the new product idea being pursued by the product manager could represent a change to the company’s existing business model. As such, because of the potential impact on the company’s existing business model, a critical consideration for the product manager pursuing a new product is whether the new product is aligned with the company’s corporate strategy.

In his book, Product Leadership: Creating and Launching Superior New Products, author Robert G. Cooper talks about the need for new product development efforts to be closely linked to the overall business strategy. In Beyond the Core, Chris Zook makes the case that the further a new product or business idea is from the core business — what he calls an “adjacency move” — the riskier it is and more prone to failure. What this means is that the more closely aligned the new product idea is to the company’s existing business strategy, the more favorably it will be looked upon by the company’s executives. This does not mean something completely outside of a company’s existing core will never be approved. But it does mean the bar to get that buy-in is much higher.

So in order for the new product idea to garner the necessary stakeholder support, its business case must be able to articulate the business opportunity it presents to the company, how it fits (or departs) from the company’s current business model and strategy, and the risks associated with pursuing it.

As such, Ash’s workflow can be modified as follows:

opportunity-company-fit

I call this stage Opportunity/Company Fit.

Critical questions for the product manager to figure out are:

  • Does the idea align with the company’s strategic goals?
  • Who do I have to convince to get buy-in?
  • Can I get a sponsor? Who?

Just like with using customer validation to achieve Problem/Solution Fit, I’m sure it’s possible to use lean principles to achieve Opportunity/Company Fit.

Lean Startup in a Large Company

I’ve started reading Ash Maurya’s book, Running Lean, and have begun educating myself on Lean Startup practices, a term trademarked by Eric Ries. It’s is a fascinating approach to launching a startup, and has a passionate cult following that’s trying to break through into mainstream practice. Being a product guy, I view startups as new product development – both require business modeling, validation with customers, investment, product build and market launch. (I’m not saying a startup is the same as NPD in an established company – I’m just saying they share similar traits.)

I like Ash’s Lean Canvas that he discusses in his book. For capturing an initial vision of a business model concept, it’s fast, concise and portable, with key building blocks identified all on one page vs. creating a 20-page or 15-slide business plan that takes too long to build and no one will ever read anyway. Multiple models or canvases can easily be sketched out in a single afternoon. It allows for fluidity, as sections can be left blank and then filled in or refined based on learnings. It also forces thinking in the present with a “get it done” attitude. Most importantly, it uses a customer-centric or “tuned in” approach. (Tuned In is another book I admire.)

Ash candidly admits the methodology he proposes in his book is for web application startups. But at the end, he throws down a challenge: “What about ‘Running Lean for X’?”

So I began to think:

  • Can Lean Startup practices be applied at an established company? At a large enterprise?
  • What about Running Lean for a B2B2C product?
  • And what if that B2B2C product wasn’t software, but a service?
  • Can Lean Startup practices be applied to Product Management?

This last question intrigued me the most, because I have always felt that Product Management could be more entrepreneurial in its approach, yet like almost all Product Managers, I’ve had Pragmatic, ZigZag, Crossing the Chasm, and other frameworks drilled into me as the gold standards for identifying, developing, positioning and launching market-driven products. If Lean Startup principles can be applied to Product Management at enterprise firms, does it challenge these tried and tested methodologies, evolve them, or – dare I say – render them obsolete?

Ash encourages his readers to field-test concepts and models first-hand. I like that approach. And because I do currently work at a large B2B2C company that sells services rather than software or tangible products, I’m doing just that. I started applying Running Lean and Lean Startup concepts on some new ideas I’m kicking around. The focus, as Ash encourages in his book, is “Validated Learning”. As I tried to capture my vision onto a Lean Canvas, I immediately ran into challenges:

Who is the real target customer? In B2B2C, consumers may be the end-users of the product, but what if an intermediary is actually the one paying for it? So do I have two target customer segments?

The first question cascades into a series follow-up questions.

Whose problems are we really solving? If I do have two target customer segments, do I have two sets of problems to address? Two sets of solutions? Different unique value propositions for each one?

How to succinctly capture the Solution? In B2B2C, doesn’t the product ultimately have to have features appealing to both the C and the B?

Revenue streams: The nice thing about B2B2C is you can get pretty creative with revenue models. In the services industry, you can get even more creative. And that’s where again I found the Lean Canvas constraining at first. How can you concisely capture a potentially complex revenue model?

And how do I capture all of this on a 1-page Lean Canvas?

In the end, I decided to focus on the C, approach it strictly from the customer standpoint, and treat the B as a channel, largely because it made the exercise easier and thinking from the customer’s perspective comes more intuitive to me. I’m not saying this is the right approach. I’m saying it’s what allowed me to get through the exercise (so far).

I’d love to hear from you. What do you think?