House Building is not like Software Development


For several decades I have been involved in software; building software products for large companies, growing a startup, and even running a boutique consultancy for 10 years. I now do independent product development helping client turn ideas into software products.

Many times in my career I have heard software development described to a client the same way you would create a house. This metaphor made sense on the surface. A house is something that the clients could relate to. There’s a design phase where they talk about what they want, then there’s the building phase where the design is implemented.  

Does this metaphor sound familiar? It should, I have heard it from clients and other developers. But it is dangerous to use something so concrete to describe a medium as fluid as software. I now avoid using home construction as a metaphor for software development. Here’s why:

Scope can change dramatically after the contract is signed

As the client sees the product come together they reach realizations and will want to change the design. If we were building a house, it’s like the client casually mentioning that they want to add another bathroom on the second floor—right after you agreed on a price.

Unlike a house, software is made to be changed. Whereas a house is a largely static product, software needs the ability to adapt to changing demands, many of which present themselves during development. The catch is that clients cannot easily see all the work that goes into those changes, so they struggle to understand the complexity introduced with a new request.

Software processes can be complex

Building a house isn’t simple, but most people understand that first comes a design, and then you build it—that’s the process.

By contrast, software development can employ a number of flexible processes that many people aren’t familiar with. Processes like weekly stand-ups, sprints, backlogs, retrospectives give development teams the ability to quickly adjust to the changing needs to a project.

I find myself educating clients as fast as humanly possible, because without taking the time to explain how we change the software, and in-turn budget, the project would simply seize up.

The good news is that agile methodologies and the like are slowly permeating other industries and schools, but until these concepts gain wider acceptance, essential client education takes time and patience.

Cash flow will strain the client relationship.

If you apply for a construction loan, the bank wants to be sure of a few things before they’ll agree: like that you’ll pay them back, that the construction firm is legit, and that the costs of the project are reasonable. The bank won’t take the risk if any of these criteria don’t match what’s expected.

When all of these things do align, the process works well; the bank doles out money to the builder as costs build up. The builder knows that there is money, the client knows they will be spending it, and the bank controls this in the middle.

Software is nothing like that at all. To start, there’s no guarantee the client has any money, so it’s usually on the risk of the builder to pay their own people until the costs are covered. That can easily end up being 60 to 120 days depending on the terms of the agreement. It’s unfortunate, but right after a contract is agreed on, it’s a little like the developer—using their own funds— just extended credit to the client, all based on a handshake.

Sure, this can be solved by having the client pay up front. But there are always other firms willing to jump in to get the business, and the pressure is always there to just make a sale. As a development firm, it takes a lot of discipline to properly deal with the financing before the work gets started.

Estimates might be the biggest problem

In the middle of every project is the budget. For the construction industry they can get three bids from subcontractors and calculate material costs. My brother in law does this for hospitals in Missouri. As complex as this is it is fairly precise.

In contrast, for the software developer, this process is much more based on intuition and experience. Construction processes can base time and material costs on square footage, linear feet, volume, and other measurable metrics. Software lacks this hands on relationship. Estimates simply have to be summation of estimated risks. We have a couple techniques for this, but the process is wrought with variables. There are many places where this can be miscalculated. For example, the client might not have told you of everything they wanted, the developers might have misunderstood the requirements or the technology landscape can change while you are in the middle of creating the product.

These are the obvious things. Then add scope creep, legacy code, and code debt, and things can balloon quickly. If this estimate is wrong, there’s immediately a problem, and the longer that problem isn’t addressed, the bigger it’s going to be.

As developers, have ways to mitigate this, like doing development spikes to test technology and adding integrated tests to see if legacy code is usable, but in the end a number has to be agreed on, and you’ve got to do it quickly to start the project.

A better metaphor.

Let me propose farming is a better metaphor for software development.

It takes time to grow a crop, and there’s always the risk that it will fail due to weather, insects, and countless other external variables. It also takes time to grow a software product. Slowing things down increases the chances of success.

In my experience, It takes at least a month to just think through an idea. It takes at least another month to build a prototype that you can test internally, and it can easily take one to three months to produce a product that’s ready for release.

It is totally fair to say that a software product takes three to six months to grow, and at that point you basically have some young plants. It takes even more time to get it scaled up for a commercial release.

Sure there are magic fertilizers, ninja farmers, and amazing machines you can rent. But people need time to think, experience, and learn because that’s when ideas grow.

Don’t construct a house out of software, take the time to grow a product.

Incubator Retrospective


With the launch of our first internal product, , it seems like a good time to step back and review how this is going.

The backstory

Originally, I proposed how to build a self starting incubator from a consulting firm some years ago when I wrote this book. Then we tried it out with our startup zCrowd. That didn’t go so hot for several reasons, the obvious take away was it was too complicated. So we reformed as to try again.

Since January we have been working on building out one month size product. We have organized the ownership using the BS3 rules.

This is what we learned.

There are several stages

Originally I had thought we could just build something every month. Turns out there is more to it than that.

  1. It takes about one month to really think the idea through.

  2. It takes about one month to build an internal prototype.

  3. It takes about two month to build a production ready version.

I think we can get that last step down to one month. This means that we could potentially release 3 - 4 products a year at this cadence.



Just pick a name to start

Naming is hard. Pick something reasonable to name it for your internal team. But before you build the pro-version you will need the real name. You need to at least own a website to cross this threshold. Keep it simple though, just name it something descriptive so that you can get going and then keep a list somewhere of naming ideas while you play with it. Something eventually will bubble out.



One month size is perfect for building something.

Anything less and it feels too pressured, anything more and it felt like there was too much room for scope creep. This lets you focus on just one project for that month. Do note that you can be thinking through about three projects at once but we only build one at a time.



Journaling is important

Keep a document shared that you can add journal entries to. There is a chance you put this project away with nothing done. This at least leaves some account of what happened and what was learned.



Start with no goal but more of a desire

We didn’t know what was going to come out of the month except we were going to hang out. About half way through we had a much better idea of what we could accomplish. In both cases it was much smaller than what we were imagining. Everything always takes longer so as long as you can reduce your expectations you can fit it into a month.



Working alone is hard

If you buddy up then you feel like you have to accomplish some smaller goals between weeks. At least then you feel accountable.



We were not very consistent with meetings

It makes sense to set up the meeting ahead of time. Just so you can set the expectations of your spouse and friends.



The first phase is really the “Play Phase”.

Seems like the goal should be to get enough of the idea in place so you can play with it for the first time operating it. The second phase can then be more for a wider audience. If we keep that in mind then it is a bit easier to focus. We really just need to get far enough to share the idea.



Make user stories

Before you start, make a list of user stories just so you can have some idea of what needs to be accomplished. It is an easy way to get people on the same page and I found I immediately needed them as soon as the build was underway.



Make wireframes

It doesn’t take more than an hour and it helps to get your thoughts organized so that everyone can see what we are talking about.



Set measurable goals

Make sure each week you state what you are going to get done by next week. It seemed like there were several weeks when things didn’t get done.



Save a day for your projects

It’s easy to overbook client work but that means you aren’t doing any of your own stuff. It is a constant battle to try and give clients what they want, have a good work life balance and then save some time for yourself. We set aside a day a week for this sort of thing.


Overall this process is working well. We find ourselves talking about the next month projects while also getting excited about this month. My sense is that if we keep making the initial projects some of them will keep us excited enough to merit a next month.

If you find yourself organizing the same thing, please tell me how your incubator is doing. What have you learned or done differently?

Structured Conversations


Too Much Noise

There is a problem with comments on the internet. We can write anything, in any form, in any way we want. The reason this is a problem is that it can be hard to keep on the topic and have the conversation get to anything useful.

People distract, people use fallacies, they change the topic, they avoid sensitive topics, they interrupt because they want attention. This is just people and it prevents us from every getting to something of value in a conversation.

The problem gets worse when there are lots of us. Like at a meeting, or on matters of politics where we want to be heard.

Here at MoP we have been thinking about this a lot over the last couple months. What we want to introduce is a concept we are calling a structured conversation. You have seen this before. They are used in therapy with I Messages. In software engineering we have User Stories. As a kid you might have used Mad Libs. The trick is in limiting what we can say into a form that pushes the conversation forward.

You might ask, why is this important?

After we started thinking along these lines we have realized how powerful this can be in a group setting. Different patterns can be used to achieve different effects from a group; entertain, create, debate, and decide. But it all came down to the simple act of planning out how to setup the conversation and to find a way to visualize the end result.

Really this article is just a teaser for what we are working on in the background. Stay tuned as we release several products to toy with these concepts.

In the meantime, maybe you see patterns of conversation that are successful in helping teams focus? I would always be interested in these so feel free to contact us.

User stories are not the hip way to write requirements.

Screen Shot 2017-07-23 at 6.57.50 AM.png

Managers that don’t understand user stories write them like this.

  1. As a user I want to choose my engagement mode so that I can listen to the radio, explore or plan trips, or travel.

  2. As a user I want the app to remember my mode and state so that when I background or relaunch the app I see the same screen as the last time I used it.

  3. As a user I want the app to have a consistent branding and experience across all the channels, follow user experience and implementation best practices described in the heuristic evaluation, and leverage the appropriate interaction/visual design paradigms for each channel so that the app and website are performant, intuitive, and delightful on iOS and Android devices as well as desktop browsers.

  4. As a user I want the app size to be 100 MB so that it is compatible with iOS OTA downloading footprint size limits for cellular installations.

  5. As a user I want the app to be mindful of data and processor/memory usage, utilize data compression and other efficient downloading/caching/backgrounding strategies, and have graceful degradation features so that the app doesn’t exceed the average cellular data plan or drain the device’s battery and also has good performance and audio quality regardless of my network type or connection strength.

Capturing a vision is hard. For folks that operate in the abstract a conversation might be enough. For more concrete personalities it feels like we should explain exactly what is desired so that it is written down with precision. Somewhere in the middle of this spectrum exist enough information to get to the next meeting. For me that is the user story.

The magic of agile development is iterations. We are not going to have just one meeting where the requirements are handed down and then the engineers build what was specified. Instead we are going to have one meeting to decide what is going to be built and when those first user stories are going to be completed. Then there will be a show and tell and we will go through this process again.

To write good user stories it is good to think about it with the INVEST mnemonic created by Bill Wake. 

Independent : Is the story dependent on another story?

Negotiable : Can you push back on this story and discuss it with the business owners?

Valuable : Does the story provide value to the stakeholder?

Estimable : Can you estimate how many days you can do this story?

Small : Can you break the story into multiple stories until it fits an agreed on minimum size?

Testable : How are you going to test that this story was completed?

If you look back at the original stories I started this article with you can see that there are many of these questions that cannot be answered and therefor they need to be rewritten.

I think what really stands out for me is that these stories are written from what the manager wanted and not from what the customer wanted. This is a very easy mistake to make. It requires discipline to remember that the product is being built for a customer and each story needs to focus on what the user wants and why.

Requirements documents kill creativity and slow the product design. They make the assumption that we already know everything we are going to know and can therefore decide all of these things now. It’s easy to get into the mindset where you just tell them what you want and expect that to be what they build. But, software has gotten faster to rewrite and that changeability is what makes it so powerful. In software, it changes overnight so only plan one sprint at a time because you never know what will happen next.

Kevin's Refactoring Kata

How to fix that old software.

Have you ever rewritten code from another developer? It is an exhausting and painfully frustrating battle. If you do everything right, then it looks like nothing changed. It usually involved lots of wandering around the code only to find that they are tracking state in the an obscure variable. At some point you just want to throw the whole thing out. 


My friend Kevin approaches software development unlike any other developer I have ever met. He does an amazing job rewriting old code and repairing old systems. I took it upon myself to study what he is doing because it is so very powerful and useful. What I realized is that it is a repeatable set of steps. Like a martial art kata. If you can master this way of thinking you can make incremental improvements on your software one test at a time. This allows you to incrementally make it a well tested, easy to reason about system, that is much more maintainable for the life of the software.

Kevin’s Refactoring Kata

Step 1: Look at the system or component as a whole and regroup the functionality.

Step 2: Let each of your new components do one thing and do it well.

Step 3: Write your tests first describing all the behaviors you know it will need.

Step 4: Write your code new and use the old code as a reference.

Step 5: Get all the test to work.

Step 6: Swap it out.


Now to elaborate

Step 1: Look at the system or component as a whole and regroup the functionality.

First identify what the code is doing and what the behavior is suppose to be. This can be tricky because software sometimes has become entwined with other components and behaviors. For instance, they might be using a column in a database to represent state that triggers something else in the system. The advice here is to keep getting smaller until you can actually identify a component. Start with that. If you are unsure, start somewhere else. With every tests it will become easier to sort out what is going on.

Step 2: Let each of your new components do one thing and do it well.

This is based on the S “Single responsibility” in SOLID. It helps to start by naming the new component better. Try to name it things like CheckinService or CheckInController. Not something so vague like UserManager. In fact, try never to name it “Manager” or “Util”. These tend to create software with overloaded functionality. It’s like the box in the garage called “Misc” which is full of all the random bits that you don’t know where else to put them. Once you have your name then it is easier to make sure you know what it does.

 Step 3: Write your tests first describing all the behaviors you know it will need.

In this step just think through what this component does. Does it add more users? Does it make sure that users have a special permission? What does it do if given a bad user? Just list all of these as if they are tests. Make sure these test don’t cause it to fail but simply list the behaviors you are expecting.

 Step 4: Write your code new and use the old code as a reference.

Make your new component alongside the old chunk of code. Then start with the first test and write it. It should fail!  Now go add some code to the new component until it doesn’t. Keep going though this loop adding tests and behaviors until this one component is well defined. When you get stuck you can use the old code as a reference to understand what the previous system did. 

Step 5: Get all the test to work

Don’t stop until you have finished the tests. What is great about this approach is that you don't have to do it all at once. If you have to take a break leave yourself a broken test so you know where to start when you get back to it. You should be able to get a test created and solved in a fairly routine way. Each one gets you closer to being done. If you find yourself feeling discouraged, just run your tests again and you can see how far you have come. It’s small but it does make you realize that you are chipping away at it.

Step 6: Swap it out

Now you get to switch your code in for the old code. After you have proven you that the system as a whole works, you get to DELETE THE OLD CODE. That really is the best part.


To conclude

I know this seems obvious when you write it this way but it is so very very easy to find yourself on an endless adventure unraveling other developers super clever ideas.  They took shortcuts, they wanted to show how brilliant they are, they didn’t make it easy to understand. By following through on these steps you are on your way to a much easier to maintain system.

What is Product Development?

What is Product Development?


To me, this means the art of turning an idea into something people want. An idea is a solution. But, if the problem it is solving isn’t big enough then it will not live. In order for it to be alive, it must have both an audience and the technology to support it. I am focused on mastering this processes of build, measure, learn to turn ideas into sustainable businesses. The important notion here is iterations. Everything happens in a circle, not a line. The process repeats until it works or until the team and resources have reached a limit.

I like to set the iteration limit to three. This is arbitrary and could be more or less. The important notion here is that three iterations sets my team's expectations. No one shows up expecting to nail it the first time. It also protects us from the Sunk Cost Fallacy. This is when you reason that further investment is necessary simply because the resources already invested will be lost. It is a nostalgic position and is dangerous because it uses your time and money on ideas that have been tried thus stunting the other ideas that you haven’t tried yet. This is the balance between sunk costs and opportunity costs.

I also believe strongly in giving yourself some time to play with an idea. Especially in the early iterations. The first iteration could very well be just building the idea so that only you can play with it. Then at least you can see if it was worth it. A common mistake is to believe your idea will be successful before you have tried it.

Product Development is a system of limits.  Here are a few...

  1. Journal as you go.

  2. Write down your assumptions early and do a retrospective later to evaluate them.

  3. Keep your first build iterations to month size projects

  4. Build the simplest thing that could possible work first.

  5. Give yourself three iterations

  6. Build then operate.

The trick to this process is in the limitations. Keep the first build as small as possible to learn as much as possible. The Ministry of Product is a Dojo of sorts for helping to explore this. I am constantly learning new ways of thinking and new ideas. This practice will never really be finished. We can only hope to continue the practice so that each of us can learn from the other and ultimately discover real paths that no one has ever taken.

We are MoP

What is the Ministry of Product?

The Ministry of Product is a community of talented developers, designers, and innovators who are passionate about the art-form of product creation. It is somewhere between an incubator and a self help group. Ultimately it boils down to a trello board, a slack channel, and some really great people.

Who is on in this group?

I limited the community to people that I have worked with in the past that I feel are genuine, dedicated, and passionate about their craft. I need to have worked on a project with you at one point to get a sense of this. Seeing how someone reacts when things aren’t going their way is part of the process.

How does it work?

Anyone can contribute a month sized project to the group so that others know what is in the backlog and can choose to participate.  It needs to have the following.

  1. A name that you have decided on and purchased a URL for.

  2. A goal that can be accomplished in one month. This should be enough to put in front of some end users and start to gather feedback.

  3. Make a card on our trello board and tell folks about it on slack.


Who owns the products?

If you build a project with us you need to use the Big Slice Small Slice (BS3) rules. This means that you are planning for multiple product build iterations with a period of operating it in the middle. If this isn’t what you are doing, you need to be very clear about that up front. My recommendations are to use BS3 to get the product to the point you are making money with the product and then everyone who is going to be part of it to still have a 3 year commitment to the project once the company launches.  Organize this as a share buyback.


Does MoP get a stake in every project?

NO, absolutely not. It is a facilitator and requires nothing from any of the members that they don’t want to freely contribute. Ownership comes from participation, so unless MoP is helping then there are no expectations.

The Month Size Project

The Month Size Project

How much time should you budget for getting your first MVP together? I think a weekend is a bit absurd, but on the other end of the spectrum you don’t want to take a year.  In the spirit of release early and often, I propose that you fit it into a month.

The Month Size Project doesn’t need to be all that intimidating. What it is intended for is to get you and your team to force your dream into a month size box. The art is in the limitations and in this case they are self imposed.

Building up to that month, it is totally OK to be thinking and laying out the groundwork. In fact it is encourages just to build some excitement; Talk to people, draw screens, research your audience. All of these help to get it going.  Then when the month arrives you and your team should already know what they are suppose to be doing and what the tools are they are using.

Before the month checklist

  • Figure out who is on your team.
  • Name your product and buy it’s website if you need one.
  • Figure out your technology stack.
  • Do some tutorials with the technology you haven’t used before.
  • Buy any services and set up accounts.
  • Map out the architecture and calls using sequence diagrams.
  • Draw your screens and get your art assets figured out.
  • Plan out times and places to meet.

During the month.

  • Set week long sprints and deploy something every week.
  • Stop doing all that other stuff you do so this gets done.
  • Block out time to work together and independently.
  • Track how much time everyone uses so you can apply it to the first BS3 slice for ownership.


Does it have to be a whole month?

No, this is a way of time boxing it together. If you can build something that you can learn something from in a smaller amount of time then do it. This is more of a tool for getting focused when you have too many ideas and tangental things going on; kids, job, etc.

Where does this fit into the BS3 rules?

This is the first development slice.

What if you need more time?

Then you didn’t trim your scope down enough or put enough time into it. Do a retrospective with your team and ask what you could have not built. Remember it is a learning experience.

How do you divide up a company before it's a company?


If you build something with a team, then this topic comes up.  Heck it comes up when you are just thinking about it. It’s the first test and sometimes the fast end to an idea.

How much do I get? How much do you get?

The faster you can get past this the better. It is the most important conversation you should have. However, it is the most stressful conversation you can have with your team as you divide nothing up between each other. The following is my idea for how you can get past this issue quickly.

BS3 rules (Big Slice, Small Slice)

Think about it like a pie chart. 4% goes to the person who originated the idea. (Yes, seriously, get over yourself it is a good idea but it isn't a company). Then split it into 3 phases. Each phase consist of building an MVP and then operating it to see if you have found a market. If in three phases you haven’t found a product market fit then it is time to call it.

  1. Phase 1 will have 16% portion for building it and 16% for operating it.

  2. Phase 2 will have 16% portion for building it and 16% for operating it.

  3. Phase 3 will have 16% portion for building it and 16% for operating it.

Now go make a spreadsheet like this.

SliceValueContributor 1Contributor 2
Original Idea4%
Phase 1 Building16%
Phase 1 Operating16%
Phase 2 Building16%
Phase 2 Operating16%
Phase 3 Building16%
Phase 3 Operating16%

The idea is that you have budgeted these specific 7 activities as the "big slices" of the entire project. What you are going to do is track who contributes to each big slice so that you can figure out their "small slice". Over time those columns under the contributors names will turn into the percentages.  The end result is a dynamically created ownership model.  

Allocating the small slices

For this part you have to change your thinking so that you represent both the company and your own interest at the same time. As the company, what are you willing to pay the contributors to put some effort into this?  Is it $100/hour?  Is it $4000 as a fixed amount? Figure that out between each of you for each phase. This is the deal you have with the company. 

What you are going to do is track these costs every month and tally it up for that slice. At the end you will have something like this.

Phase 1 BuildingContributor 1Contributor 2Contributor 3Total
Time contributed60 hours40 hours
Value Contributed$6000$2400$4000$12400
Slice Percentage48%20%32%100%
Slice of this slice7.6%3%5.4%16%

When this phase is over, go back and update that first spreadsheet.

SliceValueContributor 2Contributor 2Contributor 3
Original Idea4%4%
Phase 1 Building16%7.6%3%5.4%
Phase 1 Operating16%
Phase 2 Building16%
Phase 2 Operating16%
Phase 3 Building16%
Phase 3 Operating16%


If you didn't notice, this gives you the ability to add and remove team members easily. It gives you the ability to budget. It also gives you an idea of how much effort you have put into this so when you are negotiating with your first investor you have a clue of what you have done.

What you are really doing with this model is making up a new currency and then spending it with each other. It is what you will be doing when you raise money. But at that point it is more serious and your board will have something to say. 

Remember, the goal of this process is to get you to product market fit without raising capital. It is designed to give you a shot at testing your market three times and to pivot at least twice. You can of course extend the number of phases by following the same pattern.

Questions that have come up.

Why do I want to budget for three MVP?

You are about to form a team and find out if they are dedicated. Some will be and some won’t. It’s surprising when you look at pedigree and what people say about themselves, then you actually work on a project with them and find out what really is in their heart. You find the cynic working long hours while the ivory tower phd guy doesn’t really do anything. This process lets you set expectations for not just the people you start with but also for the people you end with. You can of course do it the other way but you will be having a lot of conversations about delusion as you have to constantly ratchet down expectations. From experience it isn’t fun to tell tell people that their 30% stake is now worth 15%. However if you start out telling them it was only 15% it is way easier.

What if this only takes one phase?

Then delete the lines for the next two phases and equalize the percentages. In this case the idea would still be worth only 4% but the first phase is worth 96%.  If you have to add a 4th phase it is the same idea. The general principal is that the idea is fixed value and the phases all have equivalent value.

Do we do this for the whole life of the company?

No, as soon as money is involved stop doing this and file it as a normal company. You can take whatever percentages you ended up at and normalize it to figure out the founders shares for filling the company as a C-Corp. 

This event might be raising capital or even better, finding enough revenue to power the company.

Can you put in real money?

Sure, as long as you and the company can agree on the 1 to 1 conversion. You might want to do this so that other contributors can buy someone else’s shares. You might want everyone to pitch in right at the beginning so that there is some capital for tools or resources.

How much time should we expect to take to build the product?

I think at a minimum you should expect 1 year to get through three phases. The max is 4 years because by then you will be absolutely sick of this idea.  But, as a team make that decision so that everyone’s expectations are the same.

Should we file something?

No, don’t make this official until the last responsible moment. Appoint someone trustable as the treasurer to handle any money contributions. This really can be just a spreadsheet to keep score.

What if we already have been building this?

Then decide what phase you are in. Most likely it is the first building phase. So just argue out how much everyone has contributed to that point. That still leaves a lot of pie left.

What do you mean by “the faster you get past this the better”? This conversation is super important and needs time to sink in for everyone.

Your biggest priority is finding product market fit. The more time you spend arguing over how much everyone gets the less time you are spending attacking the problem of creating value. This process is designed to involve contributors, see if they are worth their salt, and to get to that product market fit fast. It’s a framework for setting expectations. By simply agreeing to use a process like this you have gotten on the same page and are moving forward. The raw reality is that you will be earning your percentage which ends the debate of who is more important pretty quickly.

Is this for getting to an MVP?

No, it is for budgeting out three MVP’s in advance. You should think of it this way because you don’t know what you don’t know yet. If you are successful in the first attempt then great, ignore the later phases. I also admire your confidence.

Who is governing this process if there isn’t anything formal in place?

These rules are designed to keep the focus on finding the product market fit and setting expectations of everyone who has contributed. They should be enough to get you to that point. It will be evident who is a founder and who just wanted to have some experience. When money starts to get involved you will need to say who the founders are but I bet this will be obvious and you don’t need a process for figuring it out.

Is this an alternative to the traditional process of creating a startup?

It seems like the start story is 2-3 people work hard in a garage after hours to build a prototype and learn something special. They then raise capital, grow a company, and either IPO or get bought to have an amazing exit.
I don’t know any of these people. I know lots of brilliant middle age engineers that have families and can’t risk that. They all have clever ways to solve problems and a limited amount of time to devote toward a dream. This is for that type of person. It is possible to build and sell something without putting your family at risk.



Now go build something so you have a reason to be arguing about this.



Zen Master Kevin

Building something? Working as a team? Use these Kevin-isms to keep each other efficient, tested, and moving forward. 

I have this friend “Kevin” who has mastered how to get teams to self organize and think without being lead.  He does it with questions which he pulled from the socratic method and bits of wisdom he has collected over his career coaching and writing software.

While you are building out your dream, and you come to a point where a decision is needing to be made. Try these questions and helpful rules of thumb to simplify and get it done.

What’s the simplest thing that could possibly work?

Yes, there are some awesome things you can build and wouldn’t that be great. But you need to get it built first. What is the least you need to do?

Why not both?

Sometimes debates come down to two competing ideas, why can’t you build both of them? This question helps you figure out the argument that separates them.

How do you make this easy to reason about?

At some point you won’t remember why you build this or someone else will have to figure this out. Remove dependencies to make it easier to reason about.

Deleted code is tested code.

This saying makes you feel better when you chop away something you just spent the last week building.

Deploy early and often.

Un-deployed code has no value. If you got it built, get it out there so someone can use it.

Leave ideas in code as comments, not as features

It’s easy to suddenly have a brilliant idea, if you have to put it somewhere in the code, make a comment not a new function. Come back to it later if you still think it's awesome.

All decisions eventually become regrettable.

Don’t get hung up on debates, eventually you will learn something that unravels the original reasoning. Leaving test to document behavior and making your code easy to reason about will make it easier to change later.

Don’t build today what you can put off until tomorrow.

Be disciplined, every line of code you add is a line you have to test. So don't waste all that effort making code that isn't going to add business value.  Wait until the "last responsible moment" to add new code because that is when you will the most.

If you care, you will test it.

Tests are your chance to explain the desired behavior, this is the only way to know if you are done. Test that are being run regularly are the only real documentation of your code and project.

Build first if you are prototyping, test first if you are going to use it.

Testing first is super hard right at the beginning when you are still trying to get off the ground. But after you get something to work, start figuring out how you are going to test it.



Don’t code alone.

Buddy up, it keeps you from wasting time in a creative haze. Paired programming and pull requests will help you fight the battle against technical debt.

Make it work, make it pretty, make it fast.

Sage introduced me to this saying.  I think he actually butchered it a little but I like his version better. Looks like the source was the Unix programmer Kent Beck.

This is the simplified mantra for getting some code done. It is easy enough to remember and yet still helps as a guiding principal.

For me the reason this is so powerful is that there are a lot of competing philosophies. We are working with a medium that can do anything. By that I mean software. Given a little bit of time and some code you can make virtual worlds, control cars, control phone, or you can just keep writing todo lists in every programming language imaginable.  It is quite an overwhelming experience really. If you have all this power at your fingertips then what stops you from doing something amazing? What comes out is that it is your own personal limitations that keep you from being amazing.

I don’t think this is entirely fair since the ability to create has been amplified by technology. So don’t underestimate the effect that has on a person. It is probably like that of an author with writer's block staring at his typewriter thinking, “I can create any world on this white paper, so what is wrong with me, think, think, think, think….”

In software land you get that “analysis paralysis” and that bubbles into the imposter syndrome. As a developer it is easy to get caught up in the epic amounts of code, languages, and philosophies. A simple mantra like this is almost a beacon of light that helps you cut through the fog and get on with something.

Start with what will work. Ask yourself the questions “What is the simplest thing you could do that could possibly work?” then time box that and do it. Maybe try out the Pomodoro Technique which is just a fancy way of saying set an oven timer. That will help you focus past the first part.

After that make a test and prove that what you wrote works.  Yes, yes, yes, I know in true TDD you should write the test first. But, when you need to feel like you are moving forward I would advise you write from your heart. If you feel a boost of encouragement from seeing code work do that first. Of course you are a good developer and you will switch to the TDD approach but at the beginning of the project when nothing is written it is more important to feel joy because that is the only thing that is going to push you forward. Apathy is your biggest enemy so build what excites you first.

Once you get that bit of code and it has a way for a user to interact, look at it as a designer and try to figure out what you can remove from the UI you just created. Go reductionist and question everything. Show it to people and see how they use it. This is the “make it pretty phase”.

Finally, you are going to need to make it work fast and that is when the real puzzle solving engineering brain kicks in. Build your services, your load balancers, use map reduce. Just don’t try to do this first. Donald Knuth said “Preemptive Optimization is the root of all evil”, I agree with this so do it last if you ever do it at all.

Your company is made of meetings.

Meetings provide the structure for your company. With the right set of meetings, the right people end up talking to each other, decisions are made at the right level, and the organization learns and adapts.

HOWEVER… I have hardly ever seen it work this way.  I’m not sure if there is something called “meeting debt” but these were some of the reasons I was called to a meeting.

  1. Meetings feel productive without doing any work.
  2. At the end of the day you can say you did something, you went to a meeting.
  3. Everyone gets to be involved!
  4. Now no one feels left out because they all got to be there when things were decided.
  5. The head person gets to feel important! 
  6. It’s what we do on Tuesday!
  7. We have had this meeting forever.  Let’s not rock the boat.

These are not good reasons for a meeting. They are good reasons to justify a paycheck.  


Problems with meetings

Meeting get in the way of getting things done.

At some point somebody has to make the doughnuts around there and do the things that were expected from the last meeting. Meeting during the day mean that these folks have to work in the off hours.

Meetings are expensive.

As a business owner I would look around the room and realize that if you have 10 people at a meeting and you are paying them $100/hour then that meeting cost $1000 dollars. Most people don’t look at it this way but for the sake of the company you should.

There are smarter ways to communicate

Face to face is super effective for difficult decisions or when judgements about character are involved. They are not necessary for everything. There are countless ways to communicate which could be better.

Meetings get less effective with more people

The quiet people don’t talk when there are lots of people in the room. So if you are trying to make a classroom then you could have succeeded. Sometimes the quiet people have the best ideas. If you haven’t talked to them or figured out how to get them to talk then you can’t really argue they don’t.  Meetings don’t really pull them out of their shell. It just makes it more akward.


When you design your company’s org structure, design the meetings. This is where groups that wouldn’t normally interact need to be talking. You can use meeting to keep information from getting siloed.

  1. Design the meetings to change.
  2. If people don’t think the meeting is creating value, cancel it.
  3. If you have too many people, split the meeting. Can it be two groups?  Would that get more value out of everyone?
  4. Have retrospective meetings: This is where the company learns.
  5. Document the meeting and share that with everyone.

It really needs to be everyone’s job to write down what they got out of the meeting. Usually it makes sense to have one person take notes but let everyone add to it. Title it with a date and list who was there and why. If you don’t write it into the collective memory of the org then this was a waste of time. My favorite way to do this is to put it in a google doc so people can add to it and comment on points.