I don’t know most of my mentors. Instead, I digitally stalk them, read everything they say and watch all their interviews and talks.

This has been decisive for me in that learning from these people has proven to be incredibly fruitful in terms of my own company’s revenue.

To recruit a virtual mentor, first find someone whose success and ideas you respect. Second, find literally everything that they’ve written. Third, find everything in video that they’ve done. Finally, find all of their products or apps or books and get them too. Once you’ve consumed everything that they’ve produced, setup a google alert for them and read anything new as it comes out.

One of the best ways to grow is to take things that your mentor does and apply them to your own company.

As an example, here are mine over the last few years. As you can see, they change based on what I’m currently doing.

Current (Focused on page flow, ‘golden mechanics’, and business):

Pincus

Past (Focused on testing and clarity):

Marissa Mayer

Eric Ries (Before he switched to self-marketing-mode)

Andrew Chen

Ryan Singer + Jason

A year ago (Focused on programming):

DHH (See “A little less hokus pokus“)

Yehuda (See “Writing code that doesn’t suck”)

Ilya Grigorik (w/r/t doing interesting stuff w/ ruby)

Norvig

pg

In the wee hours a few nights ago I wrote out a long-ish reply to someone on a listhost who asked for feedback about an early version of his webapp, on which he’d spent 9 months working with freelance developers.

I come off as a bit of an asshole, but a bunch of people replied with comments like “kickass response!”, so I thought I’d post it here.

---

RE: XXX

Thanks for sharing!

A few notes from a technical perspective:

—why open-id? What % of your customers will have openid and want to use it?

—why an about page? why is that necessary / worth money pre-beta?

—why have a blog?

—why have a help page?

—the link targets for the tabs when logged in don’t take up the entire tab, which makes it hard to click.

—why have messages?

—why have time and date settings?

—why have privacy settings?

—the language isn’t consistent. when I go to the “runs” tab, why does it say “add a workout” rather than “add a run”?

—why are there lightboxes? lightboxes tend to add/hamper development time without adding much value early on.

—why do lots of the buttons have images? why is that necessary?

—why are there rounded corners?

—why are there tweets?

—it seems like rather than “leveraging” online social apps, a lot of the features replicate other social sites. e.g. using fb connect and linking to send messages via facebook or e-mail and pulling in tweets via twitter’s api vs building all those features yourself.

As you can see, my general feeling is the app appears a bit feature-laden even in pre-beta. From a tech perspective, there are a lot of things like rounded corners, lightboxes, ajax, etc that are costing you tons of freelancer time / money but can’t really be justified in terms of any value add before you have a chance to see if customers will pay for the core product.

In terms of the biz model,

[cutting this out, since it's not that general]

My advice would be to cut out all but 2 or 3 features and then launch as is and try to get clubs to pay outright rather than just signup for a free beta.

My points might sound harsh, but I learned a lot of these things the hard way myself!

Best,

43,000 is a pretty small number in the web 2.0 world.

However, it’s a pretty big number of people to fuck up in front of. Here are a few lessons I’ve learned the hard way on how to avoid major embarrassments.

Track errors

This one is obvious. Use something like hoptoad or exceptional to track errors. While error tracking prevents customers from seeing actual error pages, the rest of the tips below are geared to avoiding silent problems.

Follow up on anything weird

Any bug report or feedback you get that sounds crazy or out of the ordinary might be the first and only warning of a big problem. Don’t ignore these just because they sound like crazy users.

Follow up on your intuition

That annoying feeling in the back of your mind telling you that a major bug is happening is probably correct. When you have this feeling, go through all of the recent minor bugs and make sure that you didn’t miss anything.

Where there’s one, there’s usually more

Any time there is a problem in one area of the code, it’s likely that you or one of your developers made a similar mistake someplace nearby. This means that for every problem, you should analyze what the code issue was, and then try to find out where else that problem might be occurring. Failing to do this results in having an embarrassing and time consuming string of similar errors.

Manually test env changes

Environment code (for example, changing stuff that’s only used in production) is often untested. This means that changes to it aren’t caught unless you manually test them.

Track 404s

See my post on this here

Cucumber test literally everything

Weird edge cases tend to get solved and forgotten. This means that when it comes time to change code, the edge case fixes often get lost in the dust, making them reappear. To avoid this, just bite the bullet and write tests to prevent regression, even when it seems trivial.

The process should be: find the problem, write a test that reproduces it, change the test to test for the desired behavior, make the test pass.

Here’s a useful process for coming up with product improvements to a/b test. It’s for sites using the trial -> upsell -> monthly payments model.

Segment

Which segment of your customers do you want to target? If you are a startup, you probably want to target your most interested users: people who know they have the problem your app tries to solve, who have tried makeshift solutions, and who are willing to pay for a better solution.

What are they doing now?

Use your current dataset to figure out what this segment currently does from the second they arrive on your site to the second they leave.

Find the most common patterns.

What do they want? What are their incentives / pain points / goals?

Using your current survey dataset, validate your assumptions about what the segement wants to do when they come to your site. What are their immediate goals that drove them to your site in the first place? What are their longer term goals in life?

What do I want

1) Hopefully the first thing you want should be to solve your customers’ immediate goals.

1.5) The intermediate thing you want is probably going to be something related to showing the customer that you can also solve their larger goal / help them with their main pain point.

2) And of course you also want them to pay you.

How do I measure what I want?

Figure out a way to measure whether or not you are actually solving your customers’ immediate goals.

Figure out a way to measure whether you are properly using their longer-term incentives to lead to longer-term engagement with your app.

Where can I intercept them?

Now that you’ve sketched out what you/your customers want, as well as what your customers are doing, choose a point in their current login -> logout process to intercept them.

Then improve a current feature or build a new feature in order to intercept them before logout and solve their immediate goal and also show them that their longer-term goals are solvable with your app.

Do it in a way that is so minimal that you’re a) embarrassed to release it b) confidant that it will allow you to learn whether your ideas are on the right track.