What’s Your Product Cadence?

I was at an board meeting yesterday morning for a new seed deal that we’ve done that will be announced next week. I love the product vision – it’s in an area that I’ve been working in for a while across a variety of companies and will take a new approach to a very old and persistent problem.

The entrepreneurs have been living the specific problem for a long time and believe they have a unique and very informed way to solve it. Given that the company has had no funding to date, the founders have been scrappy and have cobbled together a really impressive prototype that they’ve been using to get early customer feedback. It’s an ambitious product vision that will take a while to fully roll out.

In lean startup language, they’ve got a minimal viable product. However, they are faced with two choices. The first is to polish and release the current prototype. The second is to use the prototype to continue to explore and understand the specific customer fit while building a production version from scratch that incorporates much of what they learned during the prototype development.

In their case, the customer is a business customer rather than a mass market consumer web product. Consequently, having 100,000 free users is not important in the near term – I’d much rather see them have 100 paying customers which might translate in several thousand users across all of these customers, as our premise is that organizations will have between 1 and 100 early users of the product.

We spent a lot of time in the meeting talking about this choice as well as overall product cadence. We left it up to the founders to figure out what they wanted to do and what they wanted the cadence to be, but we encouraged a one year top down view, rather than a quarterly bottoms up view. We encouraged them look at where they want to be in a year (remember – this is a seed deal, so we have plenty of ability and desire to continue to fund as they make progress, with or without new investors) and work backwards to a product cadence that works for them.

I don’t know if they’ll have a once a week, twice a month, once a month, or once a quarter release cycle. But I’m fine with any of them as long as they pick the cadence and stick with it. Given my deep belief in an agile development approach, I don’t really care what’s in the actual incremental releases at this point as I fully expect the furthest out they’ll be able to see is one quarter.

It reminded me of something I often tell TechStars teams – “slow down to speed up.” I see so many startups rushing to just get stuff out, without thinking hard about “what that stuff is and why anyone would care.” Part of this is lack of understanding of what you are trying to accomplish, but some of this is a lack of product cadence. When you have a clearly defined cadence (e.g., a monthly release) you can focus on “what’s next” while in parallel explore “what’s after next.” But in the absence of a cadence, you are always working on “what’s next” and never looking out any further.

  • You are quite right to point out that choice between a focus on customers and a focus on the product.

    The thing is, a lot of companies I see don’t even realize there’s a choice. All they see is the shiny new object in front of them.

  • “slow down to speed up.” I can’t count the number of times I’ve told teammates, cofounders, or clients a variation on this (mine is “slow down to get there faster”). I like the work-backwards approach for establishing pace in early stages. Good stuff, can’t wait to hear about the lucky fundees.

  • great post brad. and very timely… just finished a meeting on these exact topics (continue with current alpha vs rebuild, launch what we got or wait for the next version, top down vs bottom up planning, milestones & scheduling, etc, etc). I was just going to write an email summary along these lines… will forward this to the team instead. thanks 🙂

    another way i have heard the time analogy is…
    “slow is smooth, and smooth is fast”

  • Wait just one second. First you said they have a minimum viable product, then you said they were going to rebuild the whole thing as a production version. That did not cause flashing red lights on your investor alarm? Is the MVP just photoshop mockups?
    The “production” version will always be behind the prototype that keeps getting tweaked, and cluttered, then cleaned. What the customer is using is the real product, even if you call it a prototype. I’ve been there done that, worked on the old system and the new.
    In one year, the risk of the swap of the customer tested system for the new unseen by customers version will be a huge mental block. So, just don’t go there. Either get the basics in the “production” system and go live with that, or make the prototype real. You’ll give yourself a multiple personality if you don’t.

    The product type also affects the cadence. If it is Saas, don’t tell the customer there is a cadence. Just deploy what you have when it is complete. The whole release train, fitting features into releases is an ugly mess. The idea is nice, but everyplace I have worked (and where I am now claims to be agile) falls back into a waterfall process. Yes the feature should slip (insert reason here), but we promised the customer, so burn out the engineers, then wonder why they quit.
    If there is a hardware component, it gets even more complicated.
    Don’t forget, if you have version numbers and are selling to big customers, you have to manage the old versions. They stay alive longer than anyone expects, like vampires, old versions of software are hard to kill. How long will the deployed MVP be supported? Really, even if the biggest customer does not want to upgrade and take the risk of loosing data and retraining the workers?
    Now I am just rambling. I must have needed to vent.

    • While I agree with part of what you say, I think you misinterpreted what we
      are going to do with the prototype.

      The prototype – which is a functional system – will be frozen and NOT
      deployed. It will continue to be shown to potential customers who will
      interact and give feedback. However, the actual initial production system
      will be a new version and the prototype will be thrown away after the
      initial production system gets built.

      I think the mistake a lot of people make is that they don’t throw away their
      first prototype. Instead, they scale up a new engineering team (adding a few
      key folks) and try to drag the prototype forward. The prototype is poorly
      designed – pretty, but not built to scale.

      Now, the production version doesn’t have a twelve month build cycle. It can
      be released within 90 days. But the learning from the prototype gets
      incorporated into a much cleaner first build. Especially in cases of
      enterprise class software, that’s a much more sustainable approach.

      I completely agree with you that there should never be two separate systems.
      My point was that seed stage startups should be willing to throw away the
      first prototype – or recognize that it’s just a prototype – rather than try
      to force it into production.

      Also, it sounds like the companies you are involved in are definitely not
      agile shops. I have many examples where waterfall has been completely
      expunged from my world.

      • I can probably be convinced that an early version 1 should be thrown away and re-engineered but the one lesson I learned through the years is NEVER rebuild from scratch to catchup. I waisted a lot of your money and my equity doing that at my last company. Version 0, I can get my head around that if know one is breathing down your neck and your neck and you aren’t playing catchup. Aside from that never rebuild.

        And “refactoring” is just a fancy word for I didn’t think it out before I did it.

        • I totally agree. Through away Version 0.1. But that’s it.

  • Product cadence is a good discipline especially at the seed startup mode when culture and good habits get established. My mantra to the product development teams at a startup is “get closure,” as in “let’s get closure on this before we open that.” BTW, closure can be ‘completed’ or ‘release with known bugs’ or ‘killed because it sucks’… just a non-zombie ending.

    Something I’ve seen repeatedly at startups is a lack of product management with very poorly defined features and requirements: “what that stuff is and why anyone would care.” Product cadence should really be in aligned with an “agile” MRD.

  • Funny had this same discussion on some things yesterday about a product we are going to launch in about 30 days.

    There are so many pluses and minuses to the different strategies but I do agree, slowing down to speed up, is a good mantra to use as a starting point.

  • Brian G

    Bey Brad, Sorry, I thought the most interesting thing about this was You were actually looking at an Enterprise investment. Has your outlook changed that much in the past year?

  • Sounds very familiar to what we did at @filtrbox, Brad. We indeed threw away the prototype and built a V2. We ultimately realized our market was B2B and not B2C, and we developed a (mostly) consistent product cadence with releases every 2-3 weeks. Thanks for sharing!

  • Sachin

    Glad to see you guys doing seed funding Brad. Some products cannot be released half way through and thus they do need some seed funding else gives the competitors (in your case sounds like there as none as the problem still exists) an idea whats coming.

    Was wondering what sort of MVP the founders had and how did they approach you guys or how did you guys connect.

    • I’ll probably do a more extensive post about this when the company announces
      the funding and launches. The MVP is usable, but lightly featured and
      definitely not scalable.

      • Sachin

        Great. Ill look forward to that post. My product not yet MVP but would help if can have your thoughts on it.

        • Email me a URL to play with whenever you are ready.

          • Sachin

            Will Do. Thanks.

  • I must have said “MVP”, “cadence”, “rhythm” and “roadmap” a hundred times today during our release planning meetings. Time to ditch extrovert and have fun building software I’ll throw away but will propel my team forward.