This is part three of a four part series covering what we’ve learned working in and with startups to build their core product. The first installment covered how to source, select and initially work with a partner to build your startup site. The second installment covered planning the project. This installment covers the process for actually building the initial product. Here is an overview of the four parts:

startup website project

Choosing a Process

Now that you’ve selected a partner and defined the project scope at a high level, it’s time to make sure you have the right process in place. In some cases the process direction will define how the contract is structured, in others it will limit your selection of partners. For these reasons, you may want to make this decision before finalizing on a partner. Many agencies (Wakefly included) are flexible on process and will use the process best suited to the project rather than assume a one size fits all approach.

There are two primary methodologies used by web development agencies: Waterfall and Agile.

Waterfall is the traditional software development methodology. Waterfall assumes a relatively fixed project scope and is made up of the following steps:

  • Planning – clarify scope by developing detailed functional requirements documentation
  • Design – develop look and feel of the site
  • Development – build the site and integration points
  • Quality Assurance – test to make sure everything works as expected on supported platforms
  • Launch – deployment logistics

The waterfall process is best suited for projects where:

  • The scope and functional requirements are or can be well known up front
  • The project must adhere to a fixed cost

Assuming you’ve defined your initial project as an MVP (this term is covered in Part 2), the waterfall process might well apply to your initial project.

While the waterfall process is a single “development cycle”, the agile process breaks the project into multiple smaller development cycles. Each cycle is time-boxed into sprints, typically 2-4 weeks in length. The goal of agile is to have a working product at the end of each sprint, even if the feature set is insufficient to go live with. Agile is best suited for projects where:

  • You’ll be collecting early customer feedback on work in progress and possibly changing course based on what you hear
  • Your timeline and budget are secondary to getting a workable course-corrected MVP out the door that you have reasonable confidence in serving the needs of your customers

Both of these processes are viable and time-tested. Which will work best for your project really depends on specifics to your project. If you have a solid idea of what you need to build for your MVP, waterfall is probably the most efficient method to do it. If you’ll be feeling your way through it and aren’t sure where you’ll end up, then agile will serve you best.

Getting Customer Feedback

Regardless of which process you choose, as a startup it will be imperative to include prospective customers or customer representatives at every review point possible throughout the project. This applies to everything from design, to page layout, to user experience, to functionality. There are rare circumstances where the founders are viable customer representatives, but be careful. In almost every case, the founders are much too close to provide the kind of valuable feedback outside customer representatives will offer.

If you’ve gotten to the point of building a product, you’ve hopefully validated the idea with a customer base who needs what you’ll be building. These are the people to reach out to for feedback during the project. Rather than invite them into calls with your agency, bring deliverables to them – either printed out or on a laptop or tablet. Show them over lunch or dinner and make giving you feedback as easy and pleasurable as possible.

Getting this type of customer feedback takes time – a lot more than it would if you were providing the sole feedback. Be sure to include sufficient time to gather high quality feedback from customer representatives in your timeline.

Developing Content

Content is often overlooked by clients building a web application. While this may not be a marketing website, and so is exempt from needing page after page of marketing content and collateral, don’t underestimate the importance of messaging within the application itself.

Consider hiring a copywriter who can help you define a content persona and the emotional feel that language within the application should give. Have that writer create examples and hone the messaging. Then have that same writer develop all of the text that will be used within the application, from online help to labels of text boxes. Doing this will ensure your product comes across to its users as consistent, branded and polished. More importantly, the right copy within the application can go along way towards engaging users and creating a relationship that will endure.

Content development takes time, so be sure to work with your project manager to ensure that the copy developed will fit into the project plan at the right points.

If you agree or disagree with any of these tips, or if you’ve run into any of these or other snags during development of a startup MVP, be sure to leave a comment. I’ll be back in another few weeks with the final installment of this series, Iterating.