David Cummings on Startups

Category: Product Mgmt

  • Push Code to Production on Day One

    OLPC developers and children developers look a...
    Image via Wikipedia

    More and more startups are instituting a policy to have newly hired software developers push a piece of code (feature or bug fix), albeit small, to the product’s production servers on their first day. The idea is that with web-based apps and software-as-a-service programs the act of making an update should be a simple process unlike the days of shipping a new product release once every year or two on disk hoping that everything was perfect (which never happened). Here are some benefits of having new engineers push code to production on day one:

    • Sets the tone for a fast release process (potentially many times a day with continuous deployment), which often results in greater developer satisfaction due to receiving input from users as fast as possible (developers love to get positive feedback on a regular basis)
    • Reiterates the fact that smaller changes lead to smaller issues and bigger changes lead to bigger issues (bite size chunks are best)
    • Provides a sense of satisfaction to the software developer on their first day that, yes, they will make an impact
    • Makes the process of write coding and seeing it live the product no longer daunting

    My recommendation is to consider having new developers push code to the production servers on their first day on the job.

    What else? What other benefits are there of pushing code to production the first day on the job?

  • Edge Cases in Startup Products

    Game-ending edge-case
    Image by wools via Flickr

    Last week I talked a bit about successful startups that from the outside appear to have an easy business to duplicate. Once you pull back the covers you might find that they are spending over a million dollars per year on pay-per-click ads to generate customers, creating a barrier to entry for most startups. There’s another less obvious aspect of successful startups that you don’t quickly see when peering in: product edge cases required for happy customers.

    Edge cases are scenarios the product has to handle that aren’t common or intuitive when first building the software. Here are some tips to think through regarding edge cases:

    • Most edge cases come from customer feedback requiring you to get the product into the customer’s hands as quickly as possible
    • Use edge cases as a way for your sales team to differentiate against upstarts (e.g. talk about the many different unique scenarios you’ve already had to solve that new companies wouldn’t have mastered yet)
    • When encountering a potential edge case ask yourself how important it is to the product and stay extremely opinionated about what does and doesn’t get into the application

    Edge cases can be one of the more challenging aspects of building great software but they also can result in happy customers when successfully addressed.

    What else? What other tips do you have about edge cases in startup products?

  • Prototyping as Fast as Wireframing

    Logo Open Source Initiative
    Image via Wikipedia

    We don’t build wireframes for new features. Did we do it before? Yes. What changed? Development technologies, including open source libraries, made it just as fast to build a prototype as to build a wireframe. I prefer the build it and “feel” it approach to the wireframe approach. Being able to use and interact with the new feature allows us to decide if we’re on the right track and make changes as necessary. Of course, once the application’s user interface has been fleshed out and many of the common user experience interactions are in place, developing a quick mock-up is literally as fast as making a wireframe.

    In order to prototype as fast as making a wireframe it also helps to be on a modern platform like Ruby on Rails or PHP on symphony. If you find that assembling the front-end components is laborious and slowing you down it is likely you aren’t getting the benefits of the latest frameworks and approaches. At some point you’ll be better off bitting the bullet and migrating to a newer technology. But, naturally, beware the rewrite of death.

    What else? What other thoughts do you have on prototyping vs wireframing first?

  • Product Review: The Resumator Applicant Tracking System

    Last week I was talking about our hiring process with my friend who runs the best IT support shop for creative firms in Atlanta and he referred me to The Resumator applicant tracking system. We promptly implemented it on our site and have been really impressed. Here’s why it resonated with us:

    • Clean, modern user interface that is fast and not Flash
    • Pricing model based on number of job postings with unlimited users works great for us (we pay $49/month for up to five jobs and they do have a free account for one job)
    • Integration with Scribed to view the submitted resume right inline (yes, it’s Flash but you can download the file)
    • Simple reports based on positions, candidates, pipelines, etc.
    • Embeddable job board and widgets to incorporate it in your site with basic color and logo customization

    I’m a fan of automating as much as possible and this is one more item to make us more efficient. If you’re looking at applicant tracking systems or want to see a good example of a well done marketing site and web app I’d recommend taking a look at them.

    What else? What other thoughts do you have about The Resumator?

     

  • Perfect is the Enemy of Good (for Product Management)

    Artist's rendering of a Mars Exploration Rover.
    Image via Wikipedia

    As I help out startups that are pre-product/market fit as well as ones that have serious traction, I continually come back to Voltaire’s quote: the perfect is the enemy of good. There’s a serious challenge with startup products pilling on functionality to try to please everyone, which pleases no one. It is much better to create a good product for a focused base of users than it is to try to create the perfect product for all users. A perfect product will never happen. A perfect product management decision will never happen.

    Instead, a culture of short, fast iterations with opinionated product management is best. A culture where new features can be brainstormed and implemented faster than the time it takes to wire-frame and detail a perfect plan. Perfect plans only need to exist for NASA. Perfect plans shouldn’t exist for startups. Startups need beta users, oxygen for the product, so that engineering is paced with customer feedback.

    Release early and often.

    What else? What are some other product management challenges with iterations and feedback?

  • Books for Software Product Managers

    The Mythical Man-Month
    Image via Wikipedia

    Product management is tough. It really is. I’ve written about it many times before (here, here, and here). In addition to learning from the school of hard knocks, there are several books out there on product management worth reading. Here are some of my favorites:

    There are many software product management related books out there but these are a few of my favorites.

    What else? What other software product management books do you like?

  • Product Managers in Startups

    A portion of the Buckhead skyline in Atlanta, ...
    Image via Wikipedia

    Four years ago I was having lunch at Ruth’s Chris steakhouse in Buckhead (they have good $10 lunches) with a local angel investor that was telling me his background (went to GA Tech and then worked for a major enterprise software company for many years). He said something that stuck with me, “Atlanta, and most places outside Silicon Valley, really suffer from a lack of strong product managers with an MBA.” Immediately, I thought to myself that a good product manager doesn’t need an MBA, rather, they need to be able to listen to customers and maintain an opinion of what the product should and should not do.

    Here are a few thoughts on product managers in startups:

    • It is one of the most critical functions that should not be underrated
    • Best done by a co-founder (yes, it’s that important)
    • Should balance ideas from prospects, customers, analysts, and competitors
    • Needs to have a strong opinion of what gets included and what doesn’t (saying no to features is even more important than saying yes as it occurs much more frequently)
    • Constantly asks the question, “Is this useful for 80% of the customers I want to have?”

    Product management is critical for successful startups and is difficult to do. I recommend reading Getting Real by 37signals as well as other resources on product management.

    What else? What other thoughts do you have about product managers in startups?

  • Core Engineering and Outsourcing in Startups

    Design of a turbine requires collaboration of ...
    Image via Wikipedia

    Two of my core tenants for startups are that one of the co-founders needs to be technical and that the engineering should be done in-house. Now, this doesn’t apply to more mature companies, or non-software/technology companies. One area to clarify is that core engineering should be done in-house while peripheral engineering can be outsourced. Core engineering is the main application and platform that provides the central value.

    Here are some potential items that can be outsourced:

    • Marketing website — only if the app is separate from the website (e.g. most B2B SaaS products)
    • Mobile app — many companies are dipping their toes in the iPhone and Android world, making it suitable to get started with an outsourced app (you shouldn’t outsource the mobile app if it is core to the business)
    • Plug-ins to other products — there are often special purpose plug-ins like those for Microsoft Office products that can be outsourced to specialists, especially if the plug-in is fairly black and white in functionality

    My recommendation is to do the core engineering in-house and consider outsourcing items that are more self contained and peripheral.

    What else? What other thoughts do you have about core engineering and outsourcing in startups?

  • Answering the Competitive Differentiation Question

    An unidentified seller in an unknown location....
    Image via Wikipedia

    One of the most common questions I get when talking to someone who is familiar with one of our competitors is “How are you guys different from xyz?” Naturally, as with most industries, there are a multitude of competitors out there, most of which we never compete against. Here are a few approaches to the competitive differentiation question:

    • Focus on target company size, industries, and verticals (e.g. SMB vs enterprise or healthcare vs financial services)
    • Address specific product functionality and use cases (e.g. feature X vs feature Y)
    • Talk about customer acquisition (sales) and service approaches (e.g. insides sales vs field sales)
    • Articulate the different corporate cultures, fundraising, and other strategies

    The most important thing to do with the competitive differentiation question is to answer it concisely and clearly. Too often when I ask others that question I get a long answer that doesn’t leave a memorable hook in my mind. Keep it short, simple, and memorable.

    What else? What other recommendations do you have for competitive differentiation questions?

  • Web App Security Considerations

    Ouro-preto
    Image via Wikipedia

    With the prominent security breach at Gawker and a major email marketing vendor recently having similar issues, web app security has been brought to the forefront. Web app security is a real challenge due to the continual arms race with crackers and all the technology plus process issues related to a large scale SaaS product.

    Here are a few web app security considerations:

    • Encrypt passwords one way as a hash with a salt in the database
    • Require passwords to be more complicated than simple words (e.g. minimum of eight characters, minimum of one number, minimum of one upper case letter, etc)
    • Provide IP address checks via email confirmation for user authentication and allowed IP ranges
    • Enable secondary authentication like PINs and challenge questions to go along with a standard password
    • Track failed sign-in attempts and expire passwords based on policies

    Of course, there are many other considerations but this is a starting point for web app security. My recommendation is to consider this type of functional early on in the engineering process.

    What else? What other web app security considerations would you add?