Skip links

StartupRob

Hi I'm Robert Johnson. I help founders to grow great businesses. Former Managing Director @Techstars. Cofounder @makersacademy

Main navigation

Rob Johnson

7 Ways to Find People for Customer Development Interviews

by 2 Comments

You’ve defined your hypotheses. You’ve determined what you want to learn from your interviews. You’ve come up with your questions.

 

Now you need to find some people.

 

Finding subjects for customer development interviews can be a challenge depending on who your target customer is, but here is a short list to hopefully jump start your search:

 

  1. Attend meetups that your target customer would likely attend
  2. Contact everyone you know who may be able to put you in touch with your target customer
  3. Leverage Twitter, Facebook or any other social network requesting an interview
  4. Use services such as OpenHours.org and Clarity.fm to find people in (or people who know people in) your target customer segment
  5. Contact bloggers who have a readership of your target customer segment
  6. Join some LinkedIn groups that have people from your target customer segment and request an interview from anyone interested in helping solve some of their problems
  7. …and most importantly, ask every interviewee if they know anyone who may also have the problem you’re trying to solve

You’ll notice that several of these options are contacting others to help connect with you with the people you need. While some people may be magnanimous enough to do this out of sheer goodwill, make it easier for them to say yes by putting it in their best interest. Tell them that you’re looking for a way to solve the problems of this customer segment and if they do help, keep them updated as your idea takes form.

I’m sure I missed a few so feel free to add some more suggestions to the comments below.

Why is Learning to Code so Hard?

by Leave a Comment

Why can some people learn how to code with relative ease, yet others fail? Why do some people graduate with a computer science degree yet struggle when they get on the job? Are software developers somehow genetically superior? Or can it be learned? If we tried to revolutionise how people learn to code, could we do it?

These are a few of the questions I used as a starting point to explore how people learn to code.

The Problem

Demand for software developers is high. Starting salaries are high. The future for a skilled developer has never been brighter.

Today we have more learning resources available than ever before. Almost all Universities teach computer science. With the expansion of “everywhere education” we can access world-class content for free on sites like iTunesU, Coursera and Udacity. We have phenomenal resources for the “teach yourself” programmer such as Michael Hartl’s Ruby on Rails tutorial and Railscasts. We’ve even seen the utilisation of cutting edge web technologies to teach in-the-browser programming from sites like CodeAcademy and CodeSchool.

But despite the selection of resources and the incentives to learn, there are still many people who try to teach themselves how to program and fail.

The Failing Points

I first interviewed a large number of people who have attempted to learn how to program, but failed somewhere along the way. I asked them questions to determine where, when and what material they were on when they decided to abandon the process. A lot of great information was gained through this process, but four points contributed to nearly every person’s decision to give up:

  1. Help sections aren’t – A novice developer using the help section is similar to someone learning German using a native German dictionary to figure out the meaning of a word. It can work, but it’s far from optimal. The terminology is simply too confusing.
  2. Sudden leap in difficulty – Nearly everyone noted that at some point in their learning they stumbled upon a sudden leap in difficulty that crippled their ability to grasp the follow-on concepts. The interesting thing was that this leap in difficulty was different for just about every student.
  3. Inconsistent learning – Trying to learn how to program in 20 minutes every other evening doesn’t cut it. Similar to elementary school where each week’s algebra work required that you understood the previous week’s principles, software development highly builds on previous concepts. If you spend too much time between reinforcement, learning gets significantly more difficult.
  4. Projects that aren’t engaging – Many people couldn’t keep their motivation because who really wants to code another to-do list?

The Experts

After seeing where people were failing, I contacted the best developers I knew in London and asked them who were the best five developers that they knew. From this I got a sizeable list of experts to interview.

I asked each of these experts a variety of questions ranging from where they saw beginners wasting the most time to what they personally did, and continue to do, to maintain their coding prowess.

Here are a couple of the more material points that came out:

Too many developers want to stay in their comfort zone. They try to bend whatever language or framework they know best to the problem at hand. This makes perfect sense if we think about it – people want to feel good about themselves and being good at something provides that feeling.[1. I discuss this concept in my essay on Persistence.]

While none of the experts explicitly stated it, I noticed that every developer I talked to stayed with the questions I asked longer than the average person would have. Instead of just blurting out the first thing that came to their mind, many of them would silently sit and look up into the corner of the room for 1-2 minutes thoroughly pensive about the question at hand. I hypothesise that this reticence to jump at the first thing that comes to mind is directly correlated to their success in programming. Many novices take the trial-and-error approach to every problem and while that can be useful, it’s not always the best tool for the job. In addition, this thorough and patient exploration of a problem likely also correlates to their stick-with-it-ness that is so prevalent and near-universally agreed to be a primary indicator of great hackers.

Lastly, I explored how developers spend their time on the job. Most tasks fell into one of four time slots:

  1. Fixing bugs and making minor changes to an existing code base
  2. Adding new features to an existing code base
  3. Writing new software from scratch
  4. Refactoring (making a material architectural change to a code base without changing the functionality – very difficult)

Editing an existing code base is what most entry-level programmers will do in a new position.

Where to go from here?

While the research is far from completed, I couldn’t be more excited about how to use this information to try and improve upon existing ways of learning how to code. Some of the revelations are a complete mystery on how to efficiently implement them into a new style of learning, while others provide clear clues on how to make the process more efficient. Some easy wins for anyone who wants to learn how to code:

  1. Commit – A few minutes here and there isn’t going to work no matter how you’re learning. If you want to learn how to code, commit to it.
  2. Use a mentor – Find an experienced developer who is willing to sit with you for even 30 minutes per week. You should be conducting much more than 30 minutes per week of self-study, but the 30 minutes of pair programming with an expert can provide significant improvements in the learning process. (Contact me if you’re interested in being a mentor or being mentored.)
  3. Build your own projects – Constantly bouncing from tutorial to tutorial can be useful to learn concepts, but the quicker you begin building your own projects the better. Exclusively using tutorials to learn is like someone who wants to be a chef but only uses recipes. It may show you how to make that exact dish, but the knowledge of the underlying concepts is where the true learning will come.
  4. Review others’ code – If you use a tutorial to learn a concept, go to GitHub and find some places where people have used that concept in an actual project.

If you’d like to learn more about the research and the programming academy that we’re building on top of it, check out MakersAcademy.com and/or email me at rob@makersacademy.com.

Follow me on Twitter @startuprob

The Foundry Investment Model

by Leave a Comment

It’s a great time to be an entrepreneur. The pace of change is continuing to accelerate and startups all over the world are disrupting industries to make processes more efficient. With this trend, we are seeing an incredible uptick in the diversity of ways to fund a startup.

Previously, an entrepreneur’s choices were limited: bootstrap or raise funding. Raising funding could be done by going to a bank, seeking out the three Fs (family, friends and fools) or raising the money from an external investor such as an angel or a venture capitalist (VC). These options have been analyzed to death so I’ll quickly skip to the newer (and more interesting) models that are starting to take hold.

First off, we’ve seen the advent of crowd-funding sites like Seedrs that allow masses of people to invest in startups that interest them in exchange for equity. (It’s similar to Kickstarter, only the “backer” gets a small equity stake in the startup.)

While there are negatives to this system [1. Usually the crowd funding platform organizing the transaction gets the right to vote on behalf of the masses. While this is less than ideal and likely a turn-off to many experienced angel investors, it’s a small price to pay for the benefit of efficient logistics.] it’s a fantastic alternative for startups and investors. From the perspective of the founder, they can raise money and get some initial market validation. (If they successfully raise funding, they’ll likely have their first customers lined up as well.) From the investor’s perspective, it can be alternative way to dip one’s toe into a new asset class.

After crowd funding, we have the often-fallaciously-interchanged accelerator and incubator models. An accelerator brings in outside teams to support them with mentorships and resources for a finite amount of time in exchange for an often single-digit percentage of equity. This model makes sense for a lot of teams that are already gaining traction but need help navigating their way to product market fit. Additionally, an increasing number of accelerators are starting to specialize in specific industry-verticals that can provide incredibly valuable resources to startups that fall under that umbrella.

An incubator on the other hand develops ideas from the inside and hires an outside team to execute on that idea. If the idea works, the outside team will usually get a portion of equity. If not, the team is sent on their way.

Accelerators and incubators each have their positives and negatives, but it’s important to note that there is very little proof that most accelerators and incubators work. For many of them like YCombinator and TechStars with easy to find track records it’s clear to quantify value, but some of the lesser known programs should be thoroughly researched before committing.

Finally, we come to what I’m going to call the “Startup Foundry” model. (Full Disclosure: I’m an Entrepreneur in Residence at Forward Labs in London where we are using something similar to this model. The opinions in this essay are mine and mine alone, not necessarily that of Forward Labs.)

The Foundry model is similar to an incubator, except that it invests in people instead of ideas. The critical flaw in the normal incubator model is that nobody knows how many iterations through customer discovery and customer development it’s going to take to get to product market fit. Plan A is most often thrown out and it’s usually Plan F or J or Z that ends up working. So the Foundry model brings in entrepreneurs, provides them with the similar support that an incubator or accelerator would provide, but allows the entrepreneur to come up with the idea [2. With some assistance] and to iterate through to profitability.

The Foundry model provides the entrepreneur with equity, all of the resources they need and continuous funding as long as the partners feel the entrepreneur is making documentable and real progress towards a profitable startup – using metrics developed and agreed upon between the partners and the founder. The Foundry assists the entrepreneur with many of the time-consuming activities that don’t always directly contribute to creating a great company, leaving the founder to concentrate on what truly important matters: building a profitable startup.

The founder needs to be disciplined about documenting lessons learned and, if progress is not being made, the idea is scrapped and the entrepreneur finds a new idea where they can leverage the learning from the previous venture. The constant cycle of learning and progressing in the Foundry model is the closest thing to Malcolm Gladwell’s “deliberate practice” that I’ve seen for entrepreneurs in the startup ecosystem.

All of this being said, there are negatives for the entrepreneur and the investors. In the Foundry model, the entrepreneur will have a minority equity stake in the startup, meaning that “success” could end in a substantially different result than if the founder had bootstrapped, and the founder doesn’t have control of the board. This risk can be slightly mitigated by doing due diligence into the organization and questioning past entrepreneurs that they’ve invested in, meeting with the partners and getting a general feel for what their intentions and goals are.

From the investors perspective, the model falls apart if the entrepreneur is not learning. It’s a great vision to say that we’re investing in the person instead of the startup. And if the entrepreneur is actually learning from their mistakes this has a high probability of success. But if the entrepreneur is not gaining an advantage from lessons learned – the model is unlikely to work as the founder will likely continue to make the same mistakes over and over. This makes the selection of entrepreneurs the most critical component for success.

No investment model is perfect for every investor and entrepreneur. Every model has positives and negatives based on a variety of factors such as funding needed, entrepreneur experience, market, idea, etc. If an entrepreneur thinks they can grow organically and aren’t concerned with rapid scaling requirements, bootstrapping may be best. If the entrepreneur has already proven the market but knows that they’ll need capital for scaling and competition, VC might be the most profitable route. Regardless of the stage of the startup, it’s great to see that investors and entrepreneurs alike have access to more alternatives than ever before.

In the upcoming decade, I anticipate an ever-increasing number of Foundry models being formed around the globe as it does an incredible job of aligning the interests of the entrepreneur with the investing entity. A byproduct of this proliferation will be teams of people that can execute with a quiver of past learnings like no model before it.

Thanks to @mattwheelr, @shadchnev and @jenslapinski for reviewing drafts of this essay. Follow me on Twitter @startuprob.

Disrupting Financial Technology

by Leave a Comment

I’m working on a new startup that has required me to do a fair bit of research into the financial trading industry. During my market research to see what tools are available, I was astounded at how complex they all were. The vast majority of the software solutions need to be downloaded instead of used in the browser, only a small fraction of those downloads work on anything other than specific versions of Windows, and they are all packed with so many features that I feel like I am trying to pilot a Boeing 747.

As my research continued, my mind kept being pulled back to Clayton Christensen’s work on value-proposition disruption. Nearly every tool’s “unique” selling proposition is something along the lines of “We have more features than the other guys.” In Christensen’s seminal work The Innovator’s Dilemma he shows us that the most disruptive technological innovations aren’t accomplished by providing incremental improvements along existing value propositions lines. (i.e. providing a 1GB hard drive when your competitors are providing 750MB drives) But instead by recognizing that the market is sufficiently satisfied with the capability of products along those lines and re-inventing the value proposition altogether. (i.e. making a hard drive that will fit into a much smaller device)

In the last few years we’ve seen this trend in software from feature-rich to minimalistic simplicity really take hold. [1. Apple helped with the concept of the single-use “app.”] (Evgeny Shadchnev pointed out to me that this is likely a side-effect consequence of that the fact that single-use applications are likely more successful than feature-rich/confusing applications, thus we see more of them.) I remember the first time that I saw Hipmunk and it was obvious that this is the direction that most software should be moving.

So this led me to the question of why this movement to simplicity is almost non-existent in fintech (financial technology)?

I started attending fintech meetups to try and get a better understanding as to why this mindset shift is lagged so acutely in this particular industry –  and it became even more confusing. I expected to show up and see a bunch of 50 year old men discussing their portfolios and complaining about how social media is poisoning all of their new recruits, but instead I found a lively group of young professionals who were excited and motivated about the prospects of what fintech could contribute to their future financial careers.

I could see the entrepreneurial spark in the eyes of so many of the them that it only compounded my confusion of the apparent lack of disruptive innovation. These people are intelligent, charismatic, driven and have the means to affect change.

But slowly the answer began to rear its ugly head.

I overheard a very intelligent and energetic gentleman say that he’s been working with a software developer for the last two years writing over 750 thousand lines of code for a solution to a problem that he sees his firm struggling with. After I ask him if he’s pursued a PO (purchase order) or done customer development, he responds with, “Who is going to pay for something that doesn’t exist yet – my product needs to be experienced in order for the value to be understood.”

The next young lady talks about how her consumer-facing solution is going to change the world and after six months of pitching VCs, she feels that she is close to securing funding. [2. There is a great tweet that recently went viral saying, “A founder celebrating raising funding is like a chef celebrating buying the ingredients.”]

More and more of these interactions took place to the point that I now believe: it’s not that there aren’t good fintech ideas out there – it’s that the individuals with the ideas don’t usually have the crossover startup expertise in order to find a profitable business model. Being in finance seems to demand so much of their time that it’s understandably difficult to be an expert in both.

It was this realization that gave me the epiphany to understand how all of these pieces fit together. Being an expert in finance is hard. Being an expert in software development is hard. Being an expert in startup entrepreneurship is hard. (Particularly customer development and the realization that your efforts should be in the search for a profitable business model, not immediately building a product.)

Each of these verticals require such a deep experiential and educational investment, it’s very rare to find a significant-enough overlap to provide the momentum needed to develop a disruptive startup. The personality traits and culture-fits are often diametrically opposed. By this I mean that the exact personality and character traits that would make one most likely to be successful in finance are likely the traits that would make them least likely to build a successfull startup and creatively work with software developers to release disruptive products. [3. This is closely related to the marginal investment lessons taught in most MBA courses.]

The same thing goes for great hackers. The hacker culture is often opposed to the culture of corporate “suits” and big finance – thus further widening the chasm between the two groups. There are very few networking events that would attract the same groups. Some of the greatest “hacks” we’ve seen are because hackers have wanted to build something great for themselves. This explains why there are 1000s of online project management software suites that are beautifully developed and nearly nothing for financial traders. [4. It’s likely that this framework of “being too difficult to find many people who master both” is likely present in other fields as well. (i.e. Medicine, Law, etc.)]

Fintech is ripe for disruption. An elegant pairing of intelligent finance professionals with lean startup and customer development experts that understand the benefit of giving good hackers problems to solve instead of wireframes could have massive results (and profits). As the industry realizes that their premise of “more features is better” isn’t accurate and that bringing powerful financial tools that are easy to use to consumers is far from impossible, we’re going to see increased investment in channeling the masses to the financial markets. I anticipate seeing more founders framing solutions in the fintech space as this industry rebounds, but that leaves a gap of opportunity for those who start exploring the space now.

Thanks to @shadchnev (Evgeny Shadchnev) for reviewing and providing incredible feedback on this essay. Follow me on Twitter @startuprob

Be a Failer to Avoid Being a Failure

by Leave a Comment

I want to be a failer.

As I continue to try and identify what separates mediocrity from greatness, this concept of action and failure continues to bubble to the surface. Many people who I personally consider to be doing (or have done) great work, such as Tim Ferris, Steve Jobs, Clayton Christensen, Napolean Hill and Brad Feld all have similar philosophies about how action is a primary ingredient in greatness.

Observe the people around you. Some people never want to make a mistake. You probably know somebody like this. There’s nothing wrong with this – it’s actually quite a noble purpose. Nobody wants to fail. But this seemingly biological instinct to never falter is likely the exact ingredient that holds many people back from achieving their true potential. Not wanting to fail, by definition, brings with it a slower process of acting and decision-making.

On the flip side of this there is another type of person, he or she is likely someone who seems careless and rash. People feel that they don’t always think things through. They make decisions with confidence and conviction but are quick to change direction if things don’t go their way. They get shit done – even if things aren’t perfect. They are failers.

General Colin Powell expected his Commanders to make decisions with 40% of the available information. [1. His 40/70 rule stated that you shouldn’t make a decision with less than 40% of the information but that you should never wait until you have more than 70%.] The reasoning behind this is that the vast majority of the time, inaction is more toxic than the wrong action. And this couldn’t be truer with startups.

It’s far easier to continue to collect information than it is to actually put the rubber to the road and act. I’ve met so many entrepreneurs in the last couple of years who absolutely love talking about their ideas. They talk about the market research they’ve done, the feature lists and the prototypes. They talk about how they’re going to disrupt the market as soon as…they perfect version one. Or find the perfect cofounder. Or get the financing to quit their job. But often these are reasons to postpone taking an action that could have a negative reaction.

The truth of the matter is if this person would just act, they would receive the information they need to take the next step. Many people, myself included, have found themselves in the grips of analysis paralysis. It’s difficult when you’re trying to make a decision to try and determine how much information you need and where the important elements truly lie. But information collecting and analysis have diminishing returns after a certain point. It’s akin to trying to stare at a motor and determine what’s wrong with it – you’re just going to have to tear the thing apart and start inspecting the pieces one-by-one.

The hard truth is that the negative consequences of indecision will only compound as one moves further into the life of a startup. Running a startup requires the team to make hundreds of decisions every day ranging in consequence from easily-reversible to completely irreversible. Steve Blank has a fantastic mantra in his book “The Startup Owner’s Manual” that says a startup team should commit to making any reversible decision before they leave the CEO’s office.

Something magical starts to happen when you become a failer. You start to almost look forward to finding out you’ve made an incorrect decision because it provides data about the problem. By failing fast and often it helps you take your ego out of the equation. You begin to see patterns in your decisions and your instincts become sharper.

I don’t care who you are, everybody fails sometimes. The only way to not fail is to not do anything. Give this a trial run and for the next week: commit to making every reversible decision within 24 hours of identifying the problem or question (better yet, shoot for 24 minutes) and act immediately upon receiving 40% of the information.

Being a failer is likely the best way to avoid being a failure.

Thanks to @stephbjohnson for providing feedback on this essay – follow my path of trying to be a failer @startuprob