Product management: When can you get this done?

tl;dr — When building our company we didn’t know about agile development, likely because I was too focussed on building the product to research how we should be building it. We chose to divide and conquer rather than execute on smaller projects together. I believe this ultimately led to worse planning, accountability and prioritization of resources, which led to spending more time than we otherwise would have on certain aspects of the business. Agile development would have encouraged us to constantly take small bites of only the highest priority material, enabling us to adjust as we go and encouraging us to react to feedback from the market along the way.

When you ask a startup CEO what s/he does at work the answer invariably sounds something like “I do a little bit of everything”. I believe this is a good thing the most part. In our case, however, I did a little bit of everything but a LOT of product development. A lot of time getting my hands dirty and coding. I took a lot of pride in doing that at the time. The work was fun, challenging, and added more value than sitting back and planning development timelines for others. When I put on my “perfect hindsight goggles” again it’s clear that this was a major misstep. Part of doing “a little bit of everything” is that you don’t commit 95% into one aspect of your business. I see now the reason why is it makes it much more difficult to manage and maintain proper perspective on the company direction as a whole.

If I had spent more time sitting back and just thinking about how we can improve and measure performance overall I probably would have stumbled upon Agile development. Since I’ve become aware of the practice I’ve noticed it everywhere. Many successful companies are firm believers in the framework for organizing their product development. Now if I’m completely honest with myself I have to be skeptical that had I actually known about the practice that we would have given it a shot. From the get-go, we organized ourselves in a way that would have made agile development difficult. I can see us convincing ourselves that our situation was unique and that we shouldn’t attempt it.

From the start we took the approach of divide and conquer. We had a lot ground to cover and not many people to do it. One of us took the API, another the pricing model, another the website, another the data collection. The goal was to get them all done over a period of months, after which point we’d have a completed product/service/business. We said it wouldn’t make sense to put the whole team on data collection. Some of us were better than others in the skills required for that and so they should put their efforts elsewhere where the marginal benefit for their time was greater.

In agile development teams work together to accomplish small isolated tasks in sequence. In a large company an entire team may be devoted to data collection, and another to the website. In a small company one team would likely work on one of those projects together, possibly switching back and forth between two separate projects. We chose an approach that resembled a large company but where each team was comprised of just one person.

This had the effect of little oversight, accountability, and a feeling of stress that an entire side of the business may fail because of you alone. As a team, we would regularly meet to discuss our current tasks at hand and goals for the upcoming days or weeks. When development estimates were missed, there was little effect because each person was working on something in isolation. It just meant a certain project wasn’t done in time and that was that. We didn’t have a good framework for estimating time to complete projects. If something ran weeks longer than expected we wouldn’t know until the project was done. We did know that it wasn’t good to stop a development effort before it was finished however. That was good intuition. But we should have planned much smaller units of development so that we could get a sense of how long something would take to complete. This could have had the effect of encouraging us to work together rather than separately. It also would have helped us to realize that on occasion a given project was so large, and would take so long, that maybe it wasn’t worth doing at that point: that maybe there were better uses of our time.

Bringing it back — Had I spent less time building the product myself I probably would have recognized the short falls of our development strategy because I would have spent more time managing and thinking about timelines and where to best spend our efforts. In my next venture I am confident this will be a higher priority than it was for me with my first company. I think the “divide and conquer” strategy contributes to the philosophy of “we know what we have to build, let’s keep our heads down and crank until it’s done”. A better approach would have been assuming we don’t know what do build, and instead constantly take small bites of only the highest priority material, enabling us to adjust as we go and encouraging us to react to feedback from the market along the way.

Lessons:

• Stuff is hard, don’t learn best practices on your own. Learn from someone else.
• You’re situation is probably not unique. It’s more likely you’re doing it wrong.