How do you manage ideas (engineering changes) in a start up?

I'm involved, as a software developer, in an early stage (pre-profit) start up. The product is at a point where the basic core is implemented and we are building out features and adding polish, so the fundamental idea of the product is solid. However, the sales and business development folks like to derail development by asking for development of quick prototypes, new features, or demos to support potential sales mid-sprint. This constant interruption derails development and causes features to take longer, because of the time it takes to re-read the code and remember where you were.

In an early stage start-up, is it appropriate for development to ask that any new features wait until the start of the next (2 week) sprint? Or is it more important to actively chase prospects with demos and prototypes? Perhaps kanban is more appropriate, so that developers can finish the task they are working on properly, but allows the injection of high priority tasks without have to wait until the end of a sprint?

The phrase "failure to plan on your part does not constitute an emergency on my part" comes to mind, but I don't know if that attitude is appropriate in a start-up, where it is important and necessary to rapidly respond to change.

Go over the 'interruptions' from the last month or so. See how many of them actually closed contracts, were implemented into the project, or otherwise made a positive net contribution.

If it looks horrible, then go to whoever owns the development process, and lay it out in a positive manner. Show what the problem is, and then start talking mutually beneficial solutions. Whoever owns the development process (probably a founder) should step up and take responsibility for this -- he has the authority to do so without offending anyone.

I think 2 week SCRUM sprints seem too long for a startup, if it means denying Sales attention for that long. BUT depending on the technology used, complexity of the product, and QA need long sprints may be required. Perhaps sprints could be shorter, perhaps one day every week could be set aside for "other stuff that needs doing", perhaps your company can hire a graphics artist (offshore) to make UI mockups of Sales' ideas before bringing them to you... Get creative, and ask some other developers in developer hangouts what works for them.

I agree with Tim - with a pre-profit company, everything about the company should be about achieving the common goal. Question is, what is being measured?

An example from a relevant slideshow on how startups operate - in this case, startup2startup:

What is your companies unit of measurement?

If it's just "advance to the next stage" or "a line of working code" perhaps you should rethink how product development relates to software development.

I would say that the two weeks sprints (SCRUM like) are an artificial constrain that could be relaxed in a situation like yours.

I'm in a similar situation and using Kanban for about two months to handle this situation and I can say that it helps a lot, specially in a startup where people usually is the principal constrain.

Nowadays my biggest problems are related to demands to abort Work in Progress (WIP) in the same day that some "emergency" happens. I don't buy that and I don't remember any case that I couldn't rearrange the "emergency" and put it on the front line of the backlog.

Sales and Marketing always want to sell what they don't have. This is a constant struggle at any company since it's actually hard to figure out what customers want.

Your VP of Engineering or lead developer has to learn to just say no. It's important that the team stays focused on building what was asked for the last time.

The other thing is to have the Sales and Marketing folks file a feature request every time they want something. Once you have the list, then you can apply efforts to it and review the list. Sometimes Sales and Marketing really does not know what development is working on and showing them will usually stop the constant interruptions.

If you really can't stand this sort of closeness to the sales side then perhaps you are better suited to a larger, more process oriented company. I don't think that is the issue though.

You mention this is "pre-profit". the sales folks are trying to do what it takes to get more sales and make profits to pay salaries (including yours). You need to work together to figure out a way to achieve the common goals of the company.

Saying no to them all the time is not an option and it is likely that just allowing continual disruption to your development schedules is also not a good idea.

I'd shy away from a heavy process for their requests, but some level of prioritization is in order.

Please let us know how things worked out and what you all did to make it work.