Refining a Project Execution Strategy

Historically, my projects have been designed to satisfy my own needs. Their utility to others after their public release as open source or similar was incidental. Projects predominantly resulted in software or a document as a the work product involving development or research to complete. Research work focused on addressing a given research question, most commonly centered on an expanded understanding of a specific area or technique. Software work was always centered around a need manifest in a loose set of requirements and design notes, less rigorous than my professional software development endeavors.

I would document and elaborate only so far as the process would refine my understanding of the proposed product sufficiently that I could push out a prototype as quickly as possible. I remember reading Atwood's post in late 2007 on software vision statements that motivated me at the time to sharpen the need for each of my side projects. Specifically I adopted the formulaic vision statement taken from Geoffrey Moore's book Crossing the Chasm, which worked well for the open source projects I was working on at the time.

When our group formed earlier this year, we quickly adopted the forum-structure of basecamp to manage our internal ideation. It seemed to work well for us, and we soon had a long list of project 'posts', each with an active comment stream refining the idea and understanding of the market. I think our first problem was the motivation behind our project selection criteria. The selection of our first project was based on a lose set of factors which boiled down to our collective intuition of which project had the best chance of success. Unfortunately even this process was abandoned on subsequent projects, which were decided pretty much on whim.

We were a team of builders, all developers or designers used to the daily grind of actually building software, and naturally this is exactly how we treated our own projects. We were students of the web authorities on technology startups, and I think we accumulated advice through our builder perspective. We initially knew we needed a monetisation plan (at least for the first project), although our second core weakness was that we were of the collective opinion that implementation was the most important aspect ("build it and they will come").

We identified what we discerned was a market and an opportunity, but we stopped short of assessing who comprised the market and what their need was, let alone refining that understanding over the iterative development of the product. We were experienced builders and we had little difficulty executing the implementation of whatever we dreamed up, although the pattern of primitive initial market research and a focus on the product was repeated for each project we executed.

I think these are absolutely crucial observations for engendering future improvement, especially given that I expect I was a large contributor to our past execution pattern.

The lack of a project vision was apparent to me when I came to write bio's and descriptions of each project for our team page. The warning signs were there, each of us always did a poor job of explaining our projects to anyone that shows a slightest bit of interest. We always knew what we were building at the time, although we were never able to reel off a clear pitch. We didn't make the time to clearly define who the product was for and what value it provided to them.

The focus on team and product over market has taken much longer for me to detect. I was looking at our projects that we had declared successful (because we had delivered), and thinking that our measure of success was faulty because user uptake and purchases remained were not growing. The clinching moment occurred recently while re-reading Marc Andreessen's guide to startups series from last year, specifically that the only thing that matters is market. It wasn't that we were a great team or that we had great products, it was we knew very little about each product's market beyond a superficial survey, and as such did not consider (let alone measure or attempt to refine) product-market fit.

A final important realisation is that as a team of builders we are used to having clients and stakeholders to go back to for ground truth on what we are building. Someone with the money enlisting us to realise their vision or need. Scratching our own (or a perceived) itch meant that we were our own stakeholder as well as development team, making the waters very muddy when arguing feature sets and user requirements. Most critically, as developers we saw product delivery and launch as the hallmark of a successful project, although our broader company goal was to create a self-sustaining business, clearly a mismatch.

Business, startup's, and 'the process a group of hackers use to building websites with the hope of turning them into businesses' is not a science. I read over and over again how nobody really has a clue, how much of the advice is personalized and retrospective making it hard to abstract patterns. 'Give it a shot' and 'build something people want' are great slogans for capable builders, I think as long as there is a savvy mentor helping to guide the ship or there are periods of self-reflection followed by self-education by the team.

With thoughts of self improvement in mind, the following are some techniques I'd like to experiment with in future project execution, perhaps an augmentation of our until now product-focused execution strategy:

• Internal Product Plan: A real and formal document that contains at a minimum the vision for the product, an elaborated description of the product features, monetisation plan, and preliminary market research (market assessment, existing product feature comparisons). This is the 'what are we doing and why' (likely a lightweight business plan), the basis for elevator pitching to anyone that will listen and more importantly a process that forces (some) deeper thought into the need for the product early on.
  
• Product Manager: Someone to take ownership of the holistic product. An internal client to be responsible for learning the market and to measure and guide the adaptive fit of the product. The project manager role would likely be a developer splitting their time, meaning the market research tasks would have to be intelligently selected based on their expected benefit.
  
• Measuring and Refining: There must be processes of measuring and improving the understanding of the market, the need for the product, and the product-market fit. For example: pre-build market tests, deeper understanding of chosen monetisation plan, and continuous conversion optimization and data-driven feature management using controlled experiments.
• Priority Queue-Driven Development: As builders that have been around the block execution is an ease, especially with foreign technologies and ill-defined requirements. It's just part of the job. Although I've ranted about software construction processes, I would keep our build process much the same as it is, although with the addition of a disciplined priority queue-based feature implementation strategy (based somewhat on Yegge's 2006 post on the practices in Google). We use trac although only as a bug tracker and feature request ticketing system. I think we could use it or a similar system to dynamically manage a suite of user stories, use comments to debate their merit, and severity to rank their ordered self-organizing consumption and completion by developers.
  

Rather than a complete execution strategy or required tasks, I'd like to experiment with facet of these techniques to assess their benefit. I think a potential problem in this particular case of execution analysis is the danger of swinging concerns too far away from product and team into business and market, simply because they have been relatively under addressed thus far. I presume level heads, metered adoption, and continuous internal questioning would help, if we can muster the diligence.

There are further concerns that remain out of scope at this time like hiring and more detailed customer development simply because we have not had the volume and thus the need to address them, although I look forward to the day.