Skip to content

Do your research

The internet makes some things frighteningly easy.  Trolling, for example.

But the fact it makes research easy is a win for everyone.  James Altucher has a post on how research helped him win a deal.  I remember when research meant you had to head to the library, look in a card catalog and/or ask a librarian, and skim through books.  If you wanted to take the information home, you used to have to check out the book.  Some books were too valuable to leave the library, so you had to make photocopies of relevant pages.

That’s all changed, obviously.  Now you can research a person or entity without leaving your home, though you still can leverage what libraries provide.  And you can research non famous people in far more depth than you ever could in the past.  When you meeting with a potential business partner, interviewee, or client, you can google the heck out of them.

The benefit of doing so is twofold.

  1. You have a better idea of how the person operates and how serious they are at whatever endeavor you are discussing
  2. You can connect to them and discuss their needs and ideas more intelligently

These are both worthwhile goals and will lead to better outcomes.  If you don’t do any research, that sends a message as well–“I don’t care much about this meeting” or “I’m too busy to do any research.”  That may be OK, but be aware that you are sending these messages.

So, if you want to do research on someone, how do you go about it?

I’d start with setting a time limit and a goal, otherwise you can get bogged down or sidetracked.  An example: “I’m researching this client and want to know their key business goal.  I’m going to invest an hour of time in this.”  Write this down, and check back in as you do your research to make sure you are heading towards your goal and not down a rabbit hole.

Then, start digging.  I used the term “google” above to refer to searching, but I’d suggest using more than one search engine, as they each give a slightly different view of the web, and I’ve definitely had useful results pop up from Bing or Duck Duck Go.  If this is a business meeting, LinkedIn connections can be useful.

If the client maintains a blog or social media account, spend some time reading that.  You don’t have to read every tweet, but getting a feel for what’s on their mind, especially in recent posts, can be illuminating.

The amount of effort to put into such research depends on how much it will help you and how important the interaction with the research subject is.  That is, if you are discussing going into business with someone, research the heck out of them.  If you are interviewing for a very interesting job, spend some time.  If, instead, this is a random coffee meeting, you may not want to invest any prep time.

You may find something disturbing in your research (a conviction report for example).  Integrate this into your decision making process, but be aware that the content may not be accurate, or may not apply to the research subject, or may be far enough in the past to be irrelevant.  Also be aware of any discrimination laws that may apply, such as employment laws.

If you find an interesting blog post or article that is relevant to my audience, you can promote it before the meeting (post it to Hacker News or Reddit, tweet it out).  Your research subject probably won’t notice, but if you’ve already done the research and found something of value, you might as well share it.  And on the off chance they do see the post, they’ll likely be flattered.

When the meeting occurs, feel free to casually mention some of the research.  I’ve been on the other side of it (someone read a blog post I wrote and mentioned it in an interview) and I can tell you it was quite a pleasant surprise.  And it can be a great starting point for a conversation.  But don’t get bogged down in discussing something the person wrote years ago, just use the research you found as a way to connect.

No matter how thoroughly you research someone online, realize that online we are all painting some kind of picture of ourselves.  Some people and companies are more transparent than others, but the mere fact that you have to pick and choose what to post means that you’re getting a curated view.  Non verbal communication matters too  If you’ve done the research, you’re ready to go into that meeting and take the connection and the relationship to the next level.

Knowledge in software development: what’s your wood lot?

Gene Logsdon, who passed away in 2016, was a farmer and a wise man.  In a recent repost (originally written in 2008), he discusses why wood is more valuable than gold.  From the post:

You can’t eat gold like you can the bounty of trees in fruits, nuts, maple syrup, and various edible mushrooms and herbal treasures of the woodland. You can’t warm yourself with gold. You can’t bask in the shade of gold. You can’t make fence posts out of gold. A gold house would be mighty expensive. You can’t make a windbreak out of gold. You can’t make furniture, violins, guitars, wall paneling, picture frames, gun stocks, tomato stakes, flooring, barns, chicken coops, and hog houses out of gold. You can’t mulch a garden with gold leaf. Gold does not take in carbon dioxide and give off oxygen to preserve an environment we can live in. Gold does not provide habitat for millions of wild animals and zillions of insects necessary for a sustainable environment. And in fact, you can make methane out of wood much more efficiently than ethanol out of corn. All gold can do is go up and down in price and invariably it turns out to be a poor investment, as many panic buyers learn the hard way.

This resonated with me.  Of course when things go awry, as they did in 2008 and 2001 (in the USA), having a pile of cash feels good.  But money is not wealth (this article covers that, as well as some other key points about capitalism).  Money can come and go, but wealth, whether knowledge, relationships or wood lots, remains with you.  Some forms of wealth require more care and feeding than others, but they all have the attribute of providing value in the real world.

When you are in software development, knowledge is a common form of wealth.  I always tell teams I lead that almost every problem we’re facing is a new one, because if it wasn’t new, it most likely would have been automated or turned into a service or library that we could use.  So there are plenty of chances to gain new knowledge.

There are a few categories of software development knowledge.

  • Domain knowledge is understanding the real world problem domain.  So, if you’ve worked, as I have, in a real estate brokerage, you understand how the business works.  Who pays for what, how money and effort flow, who the main players are and what they are called.  All of these are valuable should you work in that domain again because you can come up to speed more quickly, and you understand how the real world maps to the software system.  This type of knowledge may change, but on the order of years or decades.  (I haven’t worked in real estate since 2014, but if I went back, there’d still be many of the same concepts.)
  • General technology is fundamental to software development.  I’d put abstractions like algorithms and data structures, specific technologies like distributed systems, database indices and HTTP, and best practices like automated testing and requirements gathering into this bag.  Having this type of knowledge will let you understand a typical system even if you haven’t seen the nuts and bolts of it.  Of course, the type of general technology that is most useful to you depends on your domain, to some extent.  The general technology of a chipset engineer is different than that of a UX designer.   Within the same domain, this knowledge is good for years.
  • Specific technology knowledge are the keywords that recruiters put on job postings, and what some consultants chase after.  Elm or Elixir, Rails or React Native, Kubernetes or kvm.  These technologies are very specific.  I’m of two minds about this knowledge.  On the one hand, if you pick the right tech, you can be in very high demand and get rates commensurate with that.  On the other hand, new specific technologies are constantly being born, and keeping up with all of them, let alone becoming an expert in them, requires large investments of time (perhaps the reason for the premium).  However, I have sympathy for folks looking for specific technology expertise.  Yes, any competent software developer can pick up any language in a few weeks, but the idiosyncracies, libraries and community practices take time.  Depending on your budget, you may find it cheaper to pay someone who has acquired that knowledge elsewhen.  This knowledge ages quickly.
  • Leadership knowledge is orthogonal to software knowledge, just like domain knowledge.  Since software is built by human teams, knowing how to lead such teams toward business goals, whether formally or informally, is a valuable skill. This can include specific techniques like agile development and ‘one on ones’ and more general areas of knowledge like how to connect or communicate people and how to navigate politics.  This knowledge has a long half life and can pay dividends throughout your career.

In addition to knowledge a software developer can accumulate other forms of wealth like books, videos, and relationships.  These can all serve as credentials for a new position or (occasionally) generate passive income.

As we head into 2018, think about how you can build longer term wealth in your career by picking the right kind of knowledge.

Evolution of admin features

Time is short in a startup and the edge cases are many.  I have noticed that when I am building features for The Food Corridor, especially admin or edge case features, there is a progression based on frequency of feature need.  An example of this is something like handling a refund, which is not a core use case.

  1. The first time, the issue is handled via a developer.
  2. If it happens more than once, the process is documented in a google doc.  It might be triggered by an email from another part of the system.  We have an entire google folder called ‘operations’ which is full of such documents.
  3. The developer automates the process via a rake task.  The rake task is a thin layer around a service class, which is tested.
  4. Non technical admins get access to the process via a web interface.  The web interface plugs into the service class as well.  This web interface may handle only part of the issue, and require access to other systems (in the case of a refund, access to the payment processor).
  5. Non admin users get access to the process via a web interface.  This web interface is fully fleshed out.

For core functionality, you obviously want to push the ability to self serve to the end user as soon as possible.  It simply wouldn’t make sense for us to build out the ability to schedule bookings, limit it to a developer or admin user.

But for a lot of functionality, this progression is helpful.  The developer has time to fully understand the issue by handling it him- or herself.  The documentation generated by handling the issue manually is a great start for the requirements document.  And if an issue only pops up once every quarter, or even more rarely, a minimum amount of developer time is spent on it.  If something happens often, it is far more likely to get automated.

Moving from a feature to a product to a company

This post from Seth Levine discusses the path of a startup along this continuum:

Features provide specific point value to users. Products stitch together related features into bundles that are essentially universal in their need across the problem set you are solving (put another way, if each of your users buys your “product” for a different reason you’ve probably just created a feature set, not a true product). Companies have product that is broad enough in its use and impact that a huge number of users gain value from it in a market that is both large and where the user need is similar enough to drive broad adoption of the same solution.

It’s an interesting perspective that is worth evaluating your current organization against.  Are you in the feature, product or company phase?  Rapid application development with libraries and modern frameworks makes it really easy to move from a feature to a product phase, even though some organizations that stay in the feature space–something like this store locator app or a data product like Mattermark where extra work is required to gain value.  We certainly found that when we started The Food Corridor that features alone weren’t going to be defensible or sustainable, so we moved quickly on to being a product.

It’s also worth noting that “Company” status for a VC like Seth is probably a lot larger than a sustainable SaaS company which can feed a small team and provide a lot of value to a niche market–companies like Small Farm Central or Fileboard.  You don’t have to be a “Company” to be a success, in other words.  You don’t even have to be a “Product”.  But knowing where you are in the continuum can help you define your focus.

Do you have a first, best, affiliated customer?

I find Ben Thompson engaging reading.  In one of his best posts, he discusses how AWS has a best, first customer, Amazon.  Every service that AWS builds has an automatic flagship customer that will stress test the application.

The cost to build AWS was justified because the first and best customer is Amazon’s e-commerce business

I really enjoyed that and have been looking around other places where you can see this same pattern.  8z Real Estate, a brokerage for which I used to work, has a social media offering, zavvie, which I believe all 8z brokers are using.  One of the kitchens that use The Food Corridor has an affiliated restaurant that uses a large amount of kitchen time. Would love to hear of other examples.

All of these companies have been able to make substantial investments in infrastructure knowing that, if nothing else, the benefits will accrue to a business with the same owners.  But at the same time the subsidiary can benefit from learning from other businesses, thought benefits flow both ways.  If other real estate brokerages use zavvie in different ways, zavvie can incorporate those lessons into the software and then 8z brokers will benefit.  If that restaurant needs a special piece of equipment, the kitchen can buy it, and all other clients of the kitchen will have access to it.

Do competitors have concerns about helping the parent business, even in a roundabout manner?  Sure.  Here’s an article about how startups should be wary of being co-opted by AWS.  The brokerages that are using zavvie have to be aware of the parent company (or, perhaps to be precise, that the owners of zavvie and the owners of 8z are the same).  However, if the subsidiary company can offer a service that is unique and/or very price competitive, that may cause competitors of the parent company to ignore their concerns, at least for the time bieng.

Once you get to a certain size of business, building an affiliated business which can serve both the original business and other competitors can be a great business model.  You can gain the benefits of marketplace intelligence along with providing the subsidiary business enough runway to survive.

Customer support best practice: Shared inbox

So, both at The Food Corridor and at 8z, I saw the power of a shared inbox for support.  Sure, there are tools like Zendesk out there, but when you are just getting started, having a common inbox (typically in gmail) is a great idea.  It’s free, everyone knows how to handle it, it has a great mobile client, and it is very flexible.  It’s worth noting that both of these companies had relatively small support teams (less than 10)–once you get to a larger team, more specialized tools will be helpful.

What should you call it?  You could call it ‘support@example.com’ or ‘help@example.com’, but I’ve seen a lot of folks go with ‘hello@example.com’, which can be used for all kinds of communication.

You can also use this as the master account for other subscriptions you have, whether of business specific newsletters or SaaS tools.  If someone is signing up for something that other employees may need to use, use this as the email address.  (You may want to set up a second inbox or alias for technical tools.)  You can also augment the inbox with plugins.  Rapportive was one that I’ve tried in the past, and I love Streak for easy CRM and email scheduling.

When you are responding to customer requests from this inbox, should you sign with your name or not?  It used to drive me crazy when folks wouldn’t sign emails at 8z, because I liked to know who I was corresponding with.  Now that I’m doing customer support, I see the benefit of being anonymous.  When you have different folks signing emails, it can confuse the customer (“who am I dealing with again”).  So I’d recommend signing or not signing depending on the context.  If this is a person who you haven’t dealt with before and they have no context for who you are, leave it unsigned (or, as we do at The Food Corridor, sign with something generic–“The Food Corridor Gnomes”).  If they are an existing client, then sign it.

Finally, keep this inbox clean, otherwise the value will decrease dramatically.  Make sure you archive anything that is taken care of.  Take shifts of who ‘owns’ checking the inbox.  I’ve definitely seen folks re-forward an email so it goes to the top of the inbox, or using slack to coordinate responses.  Forward questions or information for specific individuals or teams off to their email accounts, then archive.

Talking to your customers

One of my favorite parts of The Food Corridor is talking to customers.  As the main technical force there, it’s a great opportunity for me to interact with folks whose lives my work is (hopefully) making better (and sometimes making worse).

The two main ways I do this:

  1. I do customer service.  We have zendesk and a common email inbox and I take time away from developing to answer emails.  This gives me a feel for the rough edges of our product and helps me build empathy for our users (“why couldn’t they see that you just click here and then here and then… oh, that’s why”).  It also has led to a number of bug reports that make the product better.  I also answer phone calls from our google voice number.
  2. I schedule a monthly meeting with some of our bigger customers.  These tend to be 15-60 minutes long.  This meeting lets me hear directly from them what they like about the platform, and more importantly, what is missing or broken.  I rotate among a number of different customers because I don’t want to be pulled too far in one direction, and they all have slightly different needs, but hearing from them regularly helps me triangulate.  It’s important to capture what they say in some kind of tracking system, even if you don’t execute against them for a while.  This in person call also lets me let the customer know of certain other features that are new and/or may be of interest.  Frankly, this meeting can be exhausting because of the wish list aspect of it (“oh man, what would it take to implement that?”) but I try to avoid that and just be an open listener.  I think that the customers also enjoy direct access to a developer.  This certainly doesn’t scale as well as option #1.

If you are going to pursue this:

  • make it a priority and realize it is going to affect your ability to deliver code
  • don’t get defensive when your product is criticized
  • take notes
  • seek out customers with a variety of perspectives
  • don’t commit to anything new in this call, but do let them know high level roadmap if they ask
  • ask them about items outside of your product if you have time.  This can clue you in to other problems they may have.

Customer service a different activity from developing software.  It’s very choppy, and you can encounter folks that are … having a rough day and perhaps taking it out on you.  But it also is one of the best ways to make sure that you, the person building a solution, stays in touch with the people using the solution.

Advice for the bootstrapped developer

I participated in a panel for Boulder Startup Week, but previous to the panel, thought I’d be giving a 15 minute presentation.  I was going to talk about rules for the bootstrapped developer.  At The Food Corridor, we recently celebrated one year of having customers.  In celebration of that, here are my seven guidelines:

  1. It will take longer than you think.  For any meaningful value of “it”. expect the process to take longer than planned.  Whether that is acquiring your first customer, building your product, finding help, or anything else, plan for it to take longer than you think.  Heck, this blog post is taking longer than I thought it would.
  2. Know your runway.  It’s important to know your financial runway (both for the company and for yourself).  This is fairly easy to calculate–just find out your burn rate and your money in the bank.  If you are looking at your personal financial runway, don’t forget to allow some buffer for you to find a different job–typically you won’t be able to step from a cratered startup on Friday into a full time job on Monday.  However, more important than financial runway is emotional runway.  Talk about the stress with your spouse (if applicable), think about the other emotional difficulties you may encounter, and plan for some high highs and some low lows.
  3. Extend your runway.  Again, for the financial runway, lower your burn rate as much as you can.  This will mean cutting back on spending and savings.  Make sure the family is on board.  Then you will look to find other sources of money to feed and clothe yourself.  This may include digging into savings, borrowing against assets (HELOCs work for this), borrowing from relatives, pitch competitions (TFC won two), selling assets, taking contract work, having a spouse who earns enough for the household, and/or moonlighting.
  4. Talk to your customer. This was one of the great assets that one of my co-founders brought to the table.  She had deep domain expertise and had many connections to potential customers.  We had numerous customers give us feedback, including via interviews, a month long beta test, regular product advisory councils and surveys.  You will note that this point implies you can find your customer and communicate with them in a cost effective manner.  Find where your customer congregates online.  If you don’t find a place, make one and invite your potential customers to join.
  5. Everything is borked all the time. In a startup, you just don’t have time to do everything correctly.  It can be embarrassing, but if you are building something that solves customer pain, and you’ve found the right early adopters, the customers will stick around.  Just keep improving things.  And accept a certain amount of brokenness.
  6. Know your market. This is related to talking to your customer, as that is one fantastic way to learn about your market.  There are other ways too–market research, online reading, etc.  However, as you build your product, you will surprised by what your market wants.  For instance, we thought our market would want a better UX, but were surprised when someone said our v1 UX was “great”.
  7. Make your own rules. Know that my advice and rules above are based on my experience, with my co-founders, product and skillset, in this time.  You need to do the reading and figure out what your rules are.

Joining The Food Corridor

After I left 8z, I contracted for about a year and a half. It was great fun, moving between projects, meeting a lot of new developers, and learned a lot of new things. I worked on evaluating software products and processes, supporting machine learning systems, large workflow engines, and, most recently, backend systems to stop distracted driving (they’re hiring, btw).

But I saw an email from Angellist early this year about a company looking to build a marketplace for kitchen space. (Aside: if you are interested in the labor market for startup professions, Angellist emails are great–they not only give you the company name and job description, but also typically include equity and salary–very useful information.) I replied, the conversation started, and I did some research on the company. They were pre-revenue, but the founder had been grinding it out for months and had an extensive background in the industry. Was clear they weren’t a fly by night, “we just had an idea for an app and need someone to build it” operation.

After discussions, interviews and reference checks, it became clear that this was a fantastic opportunity to join an early stage startup as a technical co-founder. So, I’m thrilled to announce that I have joined The Food Corridor as CTO/Co-Founder.

Why does this opportunity excite me so?

  • By increasing visibility and availability of shared kitchen space, it can grow the local food system, especially value add producers, across the country
  • There’s a real need for some innovative software and process solutions that we can solve
  • The founding team has the diverse set of skills needed to run a great company
  • I am looking forward to learning about the business side of a software company
  • It’s right at the intersection of two of my passions–food and technology

If you are interested in following along with the TFC journey, there’s a monthly newsletter that will be focused on shared kitchen topics.

As far as the blog, I expect to be heads down and building product, but will occasionally pop up and post.

Here’s to new adventures!