We deliver Market Intelligence to meet the specific needs of the busy executives and civic leaders we serve. We do not deliver it on paper that arrives on our clients’ desks once every 24 hours. And we do not deliver it in Word documents attached to e-mail messages.
Media Salad’s Market Intelligence Portal is really something to see. We’re proud of it – and it has been a long time (OK, so a little more than a year) in the works. Our Web-based content-management-and-delivery system will certainly evolve and improve, but it’s already operating at an impressive level given the size of our startup.
At the helm of our tech development is Dusty Candland, a software developer in Colorado who is passionate about helping early-stage companies build smart and solid tech foundations. He has worked with an array of successful startups, including Colorado venture capital firm eonBusiness Corp., and GoToast, a software firm whose advertising and marketing toolset for search-engine marketing and pay-per-click management eventually was acquired by Microsoft in 2007 — and then by Facebook. When he isn’t helping Media Salad, Dusty works with new technologies.
Let’s just say that when Dusty speaks, we listen (it also helps that he’s a really nice guy).
Recently, Dusty dished some advice that everyone who wants to transform a brilliant idea into a website or web service would be smart to heed. It boils down to this:
Proper planning will save you thousands of dollars when it’s time to work with a developer.
Better is the enemy of good enough.
Sounds obvious, right? Well, so much of the obvious has to be learned the hard way.
The easiest way to cut costs and build something that you can actually take to the marketplace is to reduce a developer’s uncertainty and the scope of the job you’re asking him or her to do.
When you don’t know exactly what you want, developers will assume the defense position, which looks like a lot of dollar signs and zeros attached to their project estimates. They’ll also create detailed spec sheets and require that every little revision be considered a change order with an associated (and often steep) cost.
Really, who can blame them?
It pays — really pays — to come up with a Minimum Viable Product (MVP). An MVP includes only those features that allow the product to be deployed. Nothing more, nothing less.
“This is great,” you say, “but I need the whole thing to be completed before I can show customers.”
Not true. You need only the very minimum that allows your site to be tested by customers. You need good enough, not better or best.
So, take a look at that wish list of yours, and remove everything you can. If you’re not sure about something, drop it. If you’re not rock-solid certain that your customers will need something, can that, too. You want your MVP to feature only enough to help you determine whether your service will solve a problem for your customers. You don’t need fancy image cropping or detailed interface customization. You don’t need tell-a-friend functionality or complex user-account systems with permissions.
Extras such as these add costs to development. They also add uncertainty to the scope of your product or service. You could wind up shelling out to build all sorts of stuff that your customers don’t want.
Remember: stick with the bare bones here. One of the very best ways to determine what those actually are is by conducting some marketing research. Ask potential customers to explain their specific pain points and how they would love to see them addressed. Listen carefully for the simplest solutions they share.
Once you’ve determined the bones of your MVP, you should build a skeleton of sorts — known as “mockups” and “wireframes” in the development world. These are basic visual guides of the structure of a website and the relationships among its pages. Wireframes should be completed before artwork and design are developed.
Sure, you could crack out a pencil and paper to sketch out the diagram of a website, but Media Salad recommends (and uses) MockFlow to build wireframes.
This is always a valuable exercise because it almost always highlights our bad assumptions and missing functionality. Our wireframes are always reviewed by another member of the Media Salad team who is an expert in user-interface development (we’ll introduce you to Jose Castillo soon) before they’re handed off to Dusty.
Building wireframes is also smart because it will help you make direct comparisons among the estimates provided by different developers competing for the job you have to offer.