Getting specific: Where Process may Help/Hurt a Startup


Getting specific: Where Process may Help/Hurt a Startup

As a continuation to my previous blog post, I thought I would get more specific with thoughts about the value of certain processes vs. the stage of the team and product-market fit. This isn’t a specific how to guide, per-say, but this provides more detail to what I think provides value and what doesn’t.

The columns in this table are the Stage of the Company (from large team to small team, with product-market fit to not yet). The rows are the processes, ranging from bigger, more time intensive work, to more specific execution work.

Description Large team in large company, or any w/ product market-fit ~50 person Startup team in Large Company, w/o Product Market Fit ~50 person Start-up Team, w/o Product Market Fit <10 person start-up team, w/o product market fit
Annual Planning A comprehensive, long-term plan that summarizes the team’s focus, major goals, priorities, and initiatives. Will take 1-2 months to draft among leader and each senior leader (In a traditional org structure of 50 people, will probably take 10 people independent time and ~5 meetings on weekly basis)
Yes. This is likely the only way that leadership (a VP managing 5 teams of 50, and then SVP, owning an organization of thousands of people) will know what is happening. Leadership needs this for long-term financial planning, resource allocation, and overall strategic planning.
Will be requested, but I would Always have some plan, but Avoid very detailed — will consume too much time/energy, and will change
Always have some plan, but Avoid detailed time consuming planning — will take lots of time/energy. Instead, be mission focused.
Quarterly Planning A comprehensive, medium-term plan that summarizes the team’s focus, major goals, priorities, and initiatives. Will take 3-5 weeks to draft among leader and each senior leader (In a traditional org structure of 50 people, will probably take ~5 people independent time and ~3-4 meetings on weekly basis) This sucks, b/c in my experience at Amazon, you will get asked to do this, and it will take a lot of time and energy. This is where Clay Christensen’s Innovators’ Dilemma best practices should come into play. Consider, as long as there is a sales and marketing dependency However, quarterly planning requires dev-scoping and planning from a long ways back, which almost becomes Waterfall. In a pre-market fit company, I think this becomes very dangerous because the work required to scope is non-trivial, it will take up devs time, and its far less time actually testing the product against the market.
Goals Goals will be based on business or key metrics. For example, one goal could be “obtain $40M in sponsored advertising revenue”, or “achieve 50,000 active weekly users on product XX” Yes. Will help focus. This will help people focus, but this is dangerous if product-market fit does not happen. Once a team adopts a goal, it can be difficult to change course. Recommend having, but the leader tracking the goal should be judicious about how to enforce. Probably. Well known goals are always important and will focus. You need to be very careful to define the right goal. If it’s too specific, the goal can go south and will focus people incorrectly. If too broad, it is demoralizing. Better to be mission focused. Having some rough goal helps focus people, but hopefully at this size, everyone will think cohesively.
Weekly (or biweekly, etc) Business & Metrics Review A sync with the correct leaders to track major business metrics. This is how to judge success and determine what is working, what isn’t, and what to focus more on
Yes – needed and is a good best practice
Maybe – the right decision makers 100% need to track this, but leadership needs to be laser-focused on metrics that matter. Otherwise, leadership will randomize employees by asking them to research little and meaningless traffic spikes. W/o some type of metric-focused methodology, people will get scattered. Yes. This is important.
Sprint Planning This is to plan the developer resources for each (usually) 2 week time cycle. This is very important to focus and delegate work clarity as the dev team grows beyond ~3 devs who can easily chat and work fluidly
Very important. This is also the stage that a team moves from small to medium, and it may be painful to adopt a new way to make decisions.
Plan a little, yes, but be very fluid.
Deployment Cycle to coordinate with Q/A As the product becomes more mature, it is important for Quality Assurance to unsure there are no regression (ie all the older versions/aspects of the software still functions property) in the product. As the team becomes bigger, the need continues to grow.  I would be surprised if you have a Q/A team here. My guess if your team will be changing the product so much, that this will not exist.
As a side note, I’ve talked a lot about Process, which the “how”. A good leader can unify a team behind a this “how” method of doing something by really leading and inspiring a vision (which really hits the “what” and “why” elements).

Comments are closed.