Startups · Engineering management

How do you balance building a product while finding your market?

Dan Kelley Managing Director

January 23rd, 2016

As a CTO of a startup, how do you balance building a product while finding your market? We have a solid foundation, but as we pursue various sales, the potential clients always have unique one-off requests. In addition to the client requests, we are learning and adapting our product to add more value.Obviously we want to close deals, but these one-offs along with other change request are starting to impact product development and quality. I'm also finding this difficult to convey to our CEO as conceptually many of the requests appear similar, but the technical approach to solving them is often different. Any thoughts, stories or help would be appreciated.

Peter Radsliff Consumer Tech Marketing & Product Executive

January 23rd, 2016

Startups don’t die of starvation, they die of indigestion! If you find yourself needing to constantly change your product requirements to satisfy customers and gain the next sale, I offer the following:
- You haven’t identified a set of product requirements that is saleable
- Your salespeople aren't selling what they have, they’re selling what they want
- You are actually in the business of being a software job shop
- You have a CEO that is scrambling for sales without a solid direction
- You are at high risk for failure
What you need to do is get the executives and product managers together and decide if you need to pivot towards a product that is different than what you are currently delivering. Or, if you actually like being a nimble job shop, ensure you have the organization and funding to be successful at that. Possibly your core code and features should be pulled back to its internal ‘kernel’ and then write APIs to enable flexible features to be built off of the core. But the problems you are encountering have to do with vision, definition and discipline, not problem customers.

Richard Sachen CEO/Founder Sunspeed Enterprises

January 23rd, 2016

You'll need to work with the CEO to define a method of prioritizing customer requests.  Here's something that was used at a prior company.  1st priority change is something that is needed in order to get customers to buy the product at all, or is important to a critical customer.  Something that the customer says, "I like your product, but it doesn't do X, so I won't use it regardless of the price."  2nd priority are items that make the product better and fill a customers need , but there's a work around.  Features that the customer will pay extra for would be in this category.  3rd priority are features are nice to have, but the customer will use the tool without them.  A lot of requests fall in this category.  The customer would like them, will still use the product, but won't pay extra for them.  4th priority are features that customers haven't requested, but may improve the user experience, or make it more efficient from a programming point of view.  You'll want to develop your own list of priorities that match your company goals and capacity.

Zac Ruiz Founder at Salt IO

January 23rd, 2016

I think one of the big problems in healthcare is that products don't get this right and eventually become so big that they do a little bit of everything but nothing awesome. I worked in the healthcare space and suffered this exact same problem. It gets messy! I peeked at your website and your platform is generic enough that it seems like it could be deployed anywhere there is a clinician and a patient. There are so many types of facilities (DoD, VA, private hospitals, doctor's offices, skilled nursing facilities, etc) and so many types of clinicians (anesthesiologists, surgeons, pediatricians, etc) that there is ultimately no escaping the one off requests.But there is a difference between finding a customer and finding a market. If Core Product + Feature (A,B) can land a surgery center and Core Product + Feature (C, D) can land a skilled nursing facility are you operating so close to the line that you *have* to take both? If so then it might be on you to bite the bullet and design that flexibility into the codebase as Peter suggests before it's too late. Or do you have the opportunity to dig into the prospective markets and be more strategic? Either way, I vote the bar should be as high for the salesmarketing folks to do that digging as it is for your team to deliver on all these new features.

Joe Emison Chief Information Officer at Xceligent

January 24th, 2016

The best advice you've gotten here is in the first comment: you need strength in numbers of feedback.

There's a lot of other advice here that will hurt you, if you're trying to maximize your reach and profit. The biggest problem with the other advice here (like the 2x2 grid concept) is that it assumes that your existing process of asking customers for feedback and synthesizing that feedback is actually leading to specifications for features that even those customers will buy (let alone others). In my experience, and in the experience of basically every good software product designer, the only way you can figure out what people will buy is to try and sell what appears to be completed product to them (which they may need to test to understand what/how it works).

This means that what you really need to do figure out how to get substantial numbers of users (which could be 3-5, or 100+, depending upon what you're doing) to validate features. And so you need a toolkit to get that validation cheaply and quickly. Most modern effective product development uses click-through demos through invision or axure today to get this validation, and then builds minimum functionality (often backed by manual processes to handle things that would take longer to code) in order to validate that users will use (and pay for) those features.

Sam McAfee Building better technology leaders and teams

January 24th, 2016

There is some great stuff here. There is one important thing missing from (nearly) all of the answers you have been given, Dan.


How you deal with this has everything to do with your long-term strategy as a company, and how your product roadmap fits into it. If you don't have a strategy, and you have a million requests flying at you all the time, it's extremely dizzying and frustrating to try and prioritize everything. You can make your 2x2 grids, and so on. That method works for situations where you have a good idea of the value and effort of each request. But it doesn't help move your company towards its goal.

[And, to deflect the immediate immediate objections from the Agile/Lean crowd (of which I am a member ;-) ) you absolutely can balance validating your product-market fit with data, AND have and pursue a long term vision.]

I have this problem you describe now, and I have had it as CTO at other companies. It's surprisingly common for the tech business, particularly with generalized platforms or solutions. If you have good product manager, this is what they live for. If you don't, you will likely have to be product manager until you do.

I actually did an interview with KeenIO's founder who talked about being pulled every which way in the beginning, when what they really wanted to build was a niche-free general solution. They managed to avoid it in the end. But I think you're in danger of those same distractions.

You and your CEO presumably have a long term vision for the state of the world in the future ("where do you see yourself in 5 years, blah blah?"). And you have your product now. How you bridge the gap between your current system and that vision is your strategy. You can change your strategy over time. You're not always going to have the right strategy. But you have to at least have some strategy.

Then, you need to ignore anything that does not move you forward toward the vision, even if it looks big and shiny. Your job as CTO is not to fulfill orders from customers like a cook. It's to build a system that fulfills the mission of the organization. If your CEO doesn't understand that, you have some expectation setting conversations you need to have.

That said, there are times when you have to set things aside for revenue reasons, and just do one of the darn one-offs. You just want that to be the exception to the rule, not the norm. Make sure it's clearly scoped and well-priced to compensate for the opportunity cost of not moving your vision forward.

I'd love to chat with you, or anyone else, about this more in real time (coffee, video chat, or whatever).

Good luck, and we're here to help you! :)

Peter Kestenbaum Advisor, Investor, Mentor to Emerging firms

January 23rd, 2016

No real solid generic answer for dealing with clients who want one offs especially given the sparse info provided.. HOWEVER ... one word of caution... when you do a one off for a client watch your IP rights... usually if you do not identify the client winds up with some IP rights to your product and even if its a 5% addition to your code makes future investment or M&A much harder... Net is that you have to maintain all IP even if client volunteers to pay for modifications or development

Mathavan Arugalaimuthu Co-Founder at AOUT Innovations -

January 24th, 2016

Dan, I am sure many startups face this issue. Making thoughtful decision is challenging, yet it is the important part of startup progress. Especially difficult to make when you are dealing with various options and  different priorities. 

A simple 2X2 quad chart can be one of the powerful instrument for establishing priorities. Placing “importance” as (low - high) in x axis and difficulties ( low - high) in y axis. 

Very important to engage your CEO and other team members to be part of this exercise and plot the items.

Lower left box items are targeted and easy to kill 

Upper left box items are luxurious items

Upper right box items are strategic items require large investment

Lower right box items are high value with less difficulty  - Quick Wins

From this chart you can easily identify the important features for the product and resolve differing opinions.  Cheers!

Phillip Fram Vice President Sales & Marketing

January 24th, 2016

Dan: The most important thing is to decide what type of company you are. If you decide to be a "one-off" company then you must design your revenue model and engineering around that decision. It means getting payed and making for design work, not just sales of the product. Your profit model has to build in profit, on the development side, not just the sale of the product sale. If you decide to be a "shelf goods" company, whether those shelf goods are software or hardware, then your revenue comes from repeated sales or SAAS, not development. By definition you will not take any 'one-off" projects. The third choice is modest customization. In this case, you will be paid for development of customized versions of your product, to cover your costs, but not to make substantial profit. You will have to define what customize you will take on, during your product development stage. It has to be part of your original product definition. Three questions you have to answer, every time you are faced with a product development decision. Is it real? Is it worth it? Can we win? If you answer no, to any of the questions, "You do not do the project!" The hardest to answer is the second question. Putting all your internal costs, including opportunity cost, against any project is difficult. We all want to chase after the next shinny thing. Evaluate how shinny that new thing is, before you chase it. Let me give you two examples. - My company made a hard goods product that used plastic and metal. We were asked, by a potential customer to change the plastic type and plate all the metal. After evaluation we determined that the new plastic would work in our current molds. The plastic cost 2X and the machines would run slower. We also got a cost for having an outside source plate the metal. - We decided not to quote any development costs. We did double our profit, on total cost to make up for what we called the "bother factor". We required a minimum order, so we could run the job economically through our factory. If we got the job, we would be very happy. If we lost it, we were indifferent, as it was plus business and not core to our markets. We won the job. - Same customer came to us with a product idea where we would have to design the product from the ground up. We did not see any other potential customer. - We loaded all development costs into NRE, Non-recurring engineering, charges with profit built in to the NRE. Then we quoted a piece part price with 2X our normal profit, with a minimum order. We won the job. The key in both examples; If we lost the jobs it was OK. Each job disrupted our normal flow of product. We were only willing to accept the disruption, if we made more than then normal profit. The lesson is, decide who you are first. Set up your engineering department around who you want to be. If you are going to customize then have a couple engineers work on customs exclusively and not your standard product. Make sure you stick to who you are and not let customers make the determination for you. If you let your customers decide, in the end, you will have a lot of happy customers and go out of business. Hope this helps.

Dimitry Rotstein Founder at Miranor

January 23rd, 2016

I have the same problem, and I'm not sure how to solve it too.
A friend of mine once told me that he uses a rule of thumb - only add/change features if this is requested by at least three independent clients. The theory is that one-offs don't add enough value to make it worthwhile, two could still be a coincidence, but three may indicate that there is a value here that is important to a large segment.
Hope that helps (if you can convince your CEO of this) - haven't tried that myself yet.

David Pariseau

January 23rd, 2016

My experience has been that some of those "one-offs" can make an entire company.  What you have to determine is what's the value of a particular feature (not always easy to gauge).  In order to make that determination a number of companies host user forums for feature requests and let the user community have "vote" on the value of requested features.  In that way you get some quantitative and qualitative (if you allow users to post comments)feedback on potential new features.  You can then assign estimated man-hours to each feature and then multiply the feature score by the resource requirements and perhaps get a rough metric on feature value?