Building a new web product: How to best setup engineers AND creatives for a win
Pre-launch startup operations are always chaotic.
That being said, equipped with your idea, team, market analysis, customer personas, early validation via surveys and interviews, and a brief overview statement (yes, do all that first), there is something simple you can do to setup your engineers and creatives for a win.
Before you go off writing code and creating wireframes/mockups, your first step should be to get your team on the same page with a high-level “overview story” of your product from the perspective of each type of user.
For example, let's say your overview statement is this one from the previous article in this series:
We believe that meetings — at least those with the intent to get stuff done — should be more efficient. Too often meetings are disorganized and have agenda items that could be discussed over email and/or do not result in specific action items owned by specific people. Therefore, to solve this problem we're going to build an app that coordinates users, meetings, agenda items, and action items.
Your overview story should then be something like this:
New User— visits our site in a web browser (on any device) and understands this is an app to make meetings more efficient by easily coordinating users, meetings, agenda items, and action items. She will be able to easily start the signup process by entering an email address. If desired, she can “contact us”, read testimonials, an “about us”, or other marketing material to help her understand the app and trust it enough to start the signup process.
Existing User — after confirming her email, she will set a password/first/last and see a dashboard where she will have the ability to (1) edit her profile (first/last/avatar/email/password), (2) add agenda items (between one or more users — ideally the team solves agenda items over email without an in-person meeting being necessary), and (3) schedule a new in-person meeting where she enters meta data (i.e. title, start time, place), agenda items, and users (via email address or names of users they are already connected to) for that meeting.
Leading up to a meeting, and during a meeting, team members can comment on agenda items. During or after a meeting, an agenda item will either be closed, remain open (e.g. for email discussion or for a future meeting), or be converted to one or more action items owned by a single user (and can be tagged w/ other users) to be completed by a specified date and time. The app should encourage action items to be SMART (i.e. simple, meaningful, attainable, realistic, and time-sensitive) — and should email tagged users (one time) if the action item is past due without being closed — something to the effect of “Hey what's up? This is past due”.
That's it.
Experienced product developers in the agile world will recognize that this is essentially a collection of user stories, i.e. statements that are traditionally designed to have a specific, engineering-friendly format:
“As a [persona], I want to [do something] so that I can [derive a benefit]”
However, while strict user stories are enormously helpful for engineers to package projects into high-level epics for new features on existing apps, I've found that when starting from scratch it's a good idea to encourage the team — both creatives AND engineers — to tell a single story together that encompasses the overall flow, then allow the engineers to flush out more rigid user stories if needed (e.g. before segmenting them into specific tasks for a project management tool…I'll write more about this in future posts, subscribe to my newsletter for updates).
This first-step process is helpful because it communicates the overall gist of the product without getting too far into the weeds; yes, unfortunately it's very common for teams start at a more granular level, which can lead to shockingly obvious features getting omitted (e.g. “whoops! We forgot the confirmation email process!”).
Also, while your engineers will cringe at statements in your overview story like “or other marketing material”, this gives your team sufficient freedom to flush out those details later in your User Interface (UI) Spec or even at the wireframes/mockups stage (all of which I'll write about in future posts).
Author's note: the basic principles I'm writing about in this series are essentially Lean methodologies applied to internal startup operations. In other words, you can think of your team as the customer and your operational strategy as the product. Each person on your team has an understandable desire for a frictionless (fast!) system without missing important steps, but the process of designing and executing such a system is the hard part. Subscribe to my newsletter and let's keep the conversation going. Thanks!
