When do you give up on a venture that's neither succeeding or failing? One thing that I learned from my stock trading days is to plan for the scenarios before you jump into a trade and then stick with the plan. Never make decisions in the heat of the moment. So I am sticking with my plan. I gave myself one year to try building a startup when we moved from London to Boston. The time is up and I have decided to move on.

Looking back, this is the most incredible and brutal experience that I've had so far. I am especially amazed that we got the helps that we did considering that Spokepoint is a bootstrapped company. I am very grateful for our unicorn designer+hacker Isaac Chansky, our brilliant software engineer intern Elizabeth Hagearty, and our Clojurescript/Reagent guru Tony Tam. Of course, the person that I learned the most from is my business co-founder, Dan Siegel.

Here's a screenshot of the current Spokepoint web application.

It has been a roller coaster year for me and the company. My co-founder will continue to soldier onward with the company. We both believe that there is something to what we're doing with Spokepoint. We just don't know how long that might take. I am moving on personally and wish him the best of luck.

I don't know exactly what I'll do next yet. I am exploring a couple directions at the moment. One lesson that I learned from this is to keep moving one baby step at a time.

I was reading this piece by Jeff Atwood on why discipline makes strong developers. Having only been doing this startup thing for less than a year so far, I am learning my way as a startup co-founder as we go. So that article got me thinking on how discipline plays a role in the context of an early-stage startup. Here are the four recurring themes that I find upon closer reflection.

1. Discipline in time
2. Discipline in focus
3. Discipline in communication
4. Discipline in seeing it through

Discipline in time

It is not easy distinguishing between working hard and working productively. As I've wrote in More Problem Solving, Less Solution Glorifying, I sometimes catch myself building "cool" things rather than just the practical things. Taking a page from the Pareto Principle, we want to focus on the 20% of effort that would deliver 80% of value to our users. It is ok in the first release if things break or don't work that well. If anyone notices it, that means your users are using your product! Ship it first before anything else. This is the discipline in making the best use of your time to deliver visible values.

Discipline in focus

We regularly hire contractors to fill our gaps (design, in particular, is our Archilles' heel). It is tempting to hire even more contractors to do more work so we can get even more things done. Getting more done is good, right? But more can add complexity. It could be complexity within the product. In which case it would unnecessarily complicate the user experience. It could also be complexity in sales. A more complex product is harder for a customer to understand and see the value of. If more doesn't add complexity, then it adds to planning. In which case, you need to be critical of your basis for why you're doing it. This is a counter-intuitive one as startups need to move fast. The nuance, as Eric Ries puts it, is that we want to make informed progress and not just haphazardly shooting in all directions. This is the discipline to remain focused via customer development-driven progress.

Discipline in communication

One way to ensure that we're focusing on the right steps to take is proper communication. The people talking to clients need to communicate what users say and don't say. The people building the product needs to communicate what are the do's and not do's. Only when the two sides can come together can we find the 20% work to deliver 80% values.

Within the engineering team, we lay out the problems and communicate our plans. My job as a team lead is to enable our engineers to solve problems and not point people to build the solution in my head. Jared Spool has a good piece on Moving from Critical Review to Critique. The article is on product development but the idea of i) focus on the problem instead of the to-do's, and ii) ask questions instead of making suggestions, are sound advice in a broader context.

Within the whole company, we need discipline to be able to speak honestly and listen without passing on judgement. That one I'm still struggling on as I have this horrible tendency to be too analytical and diving into details prematurely to new ideas.

Discipline in seeing it through

Building Glassy Media is the hardest thing I've pursued, with the double whammy that there's no way to tell what we're doing even matters. I've often described to my friends that this is a roller coaster ride. In Jessica Livingston's Founders At Work, one of the founders said it best (I'm paraphrasing here):

One day you're all optimistic and things seem to be coming together.
Then the next day, you could be all gloomy and feel like this is going
to go down in flame. Even when nothing has fundamentally changed.

I couldn't agree more. I find that the key is to keep your heads up beyond the next loop to see where you're going, enjoy the ride regardless of the outcome, stay on track, and keep at it going through one obstacle at a time.

Well, that's my take. How does discipline play a role in what you do?

I have been growing fond of this trendy Go programming language lately. We use it at Glassy Media to build services over HTTP and command line. So when we needed a Amazon Mechanical Turk interface I thought why not use Go for that too? I found an existing library in Go for interacting with Amazon Web Services. But its Mechanical Turk component is incomplete. So I dove into the source code and started patching to make it work.

A weekend of coding later, I still haven't finished. Then I realised what I was doing. I was building a cool solution but not actually solving the problem at hand. This might have been beneficial for a capable company to help contribute back to the open source community. But not where I'm at -- a new startup that's stretching thin on resources. We simply couldn't afford to lose focus at this phase. So I switched over to good ole Python. The boto Python interface to AWS worked just fine. The result was that there were no "I did this in Go" blog post to write about but our problem was solved and we moved on to the next task.

This sense of building cool solutions just for the sake of it seem common in tech. Just last week at a Go meetup, someone spoke about Using Reflections in Go. Even Rob Pike, the man himself, wrote that reflection "should be used with care and avoided unless strictly necessary". Somehow that was taken as a challenge.

I am guilty of glorifying new technologies and putting down on tried and true solutions too. On more occasions than I dare to admit at data conferences, I participated in bashing at SQL databases with the attendees. I can't speak for others, but for me it was due to ignorance. I used SQL a few times before but was put off by the data warehousing aspect of it. Having gotten more familiar with MySQL in particular over the past couple years, SQL can be simple and beautiful too. I have actually come to prefer it in some cases. Use the right tool for the right task, right?

An example of focusing on solving the problem. Here is one of the distilled tech specs we have for a component.

1. A webpage for users to view a dataset of their private contacts
2. Sorting capabilities on some of the data fields
3. Expected number of contacts per user is several hundreds
4. Limit to no more than 10 - 20 users at beta launch

Most of the efforts went into distilling our problem to make it as easy as possible. Like letting the user edit the data? Nope. UX design? Not until we figure out what data to surface. Because the problem specs are concise, solving this is almost trivial. Our current technical stack to solve this is embarassingly simplistic:

• HTML/CSS/Javascript for front end hosted on Heroku,
• Go for REST-based backend on Heroku; and
• Google Spreadsheet as database.

Nothing fancy. Yes, we didn't even bother with spinning up a database.

People build more complicated things in a hackday than this. That's because the real problem we have is that we think this is needed with no real proof yet. Perhaps all they need is just having CSV files emailed to them? We tried that too. We want to get this out to our customers as soon as possible for them to use and give us feedback. What is the task that this component is doing for our customers in the scope of our product experience? Abstract problems like these are not trivial and validating them is why we are building things in a startup. Not the other way around.

As I was reminiscing earlier this year, effective problem solving is more about defining a clear problem than coming up with a smart solution. "A problem well stated is a problem half-solved." In a pursuit of the latest and greatest, I sometimes find myself swung too far in the pendulum towards glorifying the solution rather than appreciating the effectiveness of clarifying the problem. Sometimes the best solution is to realise not to do something.

At this early stage of our startup, the biggest problem should clearly be shipping and learning. Being a Clojure enthusiast myself, we've only used Clojure for 2 of the dozen or so of projects shipped. Most of the rest are a mix of Python, Go, Javascript, Bash scripts, or even Google Doc macros. However, don't mistaken getting things done quickly with cutting corners or committing spaghetti code. We are adament about keeping our software architecture as simple and decoupled as possible. If that's done right, the individual implementation don't matter because we can always rewrite any of them without impacting the system. That Mechanical Turk project? You can bet that we'll come back to refactor it later if it proves useful. Maybe we'll pick up on goamz again. But at least it's shipped now. I am focusing on the problem and not let building a startup become a technical challenge to satisfy my vanity.

We knew early on that paying customers is the only metric that we can believe in. We have paying customers now, but we don't have a business yet until we know our product/market fit. A problem with having paying customers is that the day-to-day work of delivering and executing can drown out the big picture. Thinking in first principles helps keep us iterating towards a product/market fit while we immerse ourselves on learning from our individual customers.

The only thing that matters is getting to product/market fit.
-- Marc Andreesen, June 25, 2007

First of all, what does it getting to product/market fit mean? After some failed starts and pivots to our business, I think I sort of get it now. Here are three questions we ask ourselves to check if we are heading to a product/market fit.

1. Is this viable with the resources we have now?
2. Is this profitable before our next bills arrive?
3. Is this scalable to take us to our next stage?

One lesson we learned is to focus on the immediate future. Not 6 months down the line. Our company simply couldn't afford to try things out for 6 months with a mere chance of success. We try to find our product-market fit now to take us there, not the other way around.

As I said earlier, we have a few paying customers but we still haven't found our product/market fit yet. We have a product. With a market. But not necessarily a fit. A fit imples an optimal product and market match.

Last week, it finally dawned on me that finding a product/market fit is an optimisation problem. What are the variables that you're optimising for?

This.

Source: Wikipedia

I realised that product/market fit is supply and demand in disguise. Finding a product/market fit is an exercise in finding your supply and demand curves. This puts the abstract problem of finding product/market fit into data exploration actions to take to fill a graph.

Taking our startup as an example, this is our supply curve at the moment (drawn as a straight line for simplicity).

A bit of background. Our main product isn't a web application or a software yet, it is a service. We delivered for our first clients through hustling and manual labour. As a 3-person startup, there are only so many clients we can take on while we are developing our software tools. So our supply curve is limited by capacity and is insensitive to price.

Note that there is theoretically an infinite set of options, deliverables, and products that we can offer in our market space. The lines that we draw would be different for each set. So bear in mind that this is not an academic proof but a mental exercise to help us move systematically faster.

Now that we have our supply curve/line, we only need the demand curve to complete this graph. This is the side of the market that we are most uncertain about. What does our client really want? How much are they willing to pay?

We sold to our first clients at a price point that is a fraction of industry average to get our hands dirty and to learn if we can do this (Question #1). We quickly reached our capacity and was inundated with work to deliver on our promise. But remember that our goal is to learn our supply and demand graph and not necessarily only to learn about our individual customer needs. Referring to the supply and demand graph below where we undersold at a low price, yes, we learned about our work process, but we didn't learn anything about the demand curve at that price simply because we couldn't meet the demand. After we were at capacity, we stopped looking for clients for a couple weeks while we served the ones onboard.

Suppose our capacity is 3 clients at a time. If we sold at a higher price and had 3 of 10 people said yes (instead of 3 of 3 we had at a low price), we learned something about the price while still signing up to the same number of customers. Then we could adjust our price to a bit lower in the next round to find 3 of 7 people sign up instead. With a slight change in approach, we would be getting data about our demand curve while serving the same number of clients.

This is one illustration of how thinking in supply and demand can make us go faster. Now that we can rely on existing principles in our product/market search, we can do this systematically. Much smarter people have thought about microeonomics and laid the ground work for us to leverage. Hopefully we can find our product/market fit even faster with these principles in hand.