The Product Creation Process

Processes get especially tricky and complicated when you have a full team tackling various sections of a complicated scope.

Discovery

In order to get a holistic overview of what creating a product will entail, you have to start with a comprehensive discovery meeting. Ideally, this meeting is going to take place in-person with the client and representatives for all teams will be present. For example, if a project is going to require both extensive engineering and design, you should have an expert from your team representing both of these areas.

The objective of your discovery meeting is to turn over as many rocks as possible. Ask any questions you can possible think of while you have the full attention of your client. Depending on the project, this might be several hours or it could last a few days. This is a critical meeting time since you might not be in the room with the client again for several weeks or months. It allows you the opportunity to establish rapport and learn as much about your client’s problem as possible.

Be thorough and have a list of questions already prepared.

Proposal

After you’ve met for a discovery, you’ll have to take your notes back, distill it down, and start mapping out the scope. This will require a balance of budget and timeline.

The budget portion will require you to take all the client’s needs and wants, wrapping them into a fun little package. We usually recommend offering several tiered options to best meet their proposed needs and wants. It’s rare that clients will ever fully commit to an entire budget or full scope based on what was discussed in your discovery.

Take this opportunity to set yourself up for future engagement by proposing a V1 feature set and V2 options they can commit to down after the initial launch. This allows the client to get what they NEED within a reasonable scope and budget.

Now for timelines: This one gets tricky. Mostly because time is money and everyone always wants their product completed yesterday. Timelines become a tricky balance between time and money. The more that needs to be built out, the more time and resources you’ll need. Easy enough to understand, but you’ll have to remind your clients of this

Kick-off

Kick off is different from discovery. Remember, at discovery you might not have had an actual signed Scope of Work (SOW). Now you do and things are about to get real. You’ve done your research and pooled your internal or external resources. It’s time to get both sides jazzed and dive in! For our kick off calls, it’s a time to reiterate the problem, how we plan to solve it, gather inspiration from the client, and begin to plan your resource utilization.

From your kick off call, you’ll want to make sure you’re gathering all the basics from your client. Who will be your point person? When will you plan your weekly sync up calls?

However, it’s important to schedule at least one sync up call with the client each week. If your client is communicating throughout the week via Slack or email, there’s no reason this should last more than 30 minutes. It’s a great time to screen share and show progress or have a moment of their attention if they aren’t getting you the information you need at other times.

Internally, since our team is remote, we’re talking all.the.time. We’ll spin up a zoom meeting if we need some face to face time, otherwise, it’s Slack all day every day.

Setting milestones

Setting milestones is easier said than done. After you’ve established a rough overall timeline and mapped out expectations in your kick-off, you’ll need to set internal expectations for your team. Having milestones for your internal team to knock out sets goals and expectations so things are being built without direction.

However, I usually find milestones require a bit of flexibility. Sometimes an engineer will dive into a feature only to find it’s twice as complicated as initially understood or a client doesn’t provide timely feedback so designs can never be signed off. So use this as a strong guide, not concrete and you’ll help your team successfully stick to the proposal set forth.

Design

First step to any great design is to understand what it is your client likes and what the goal is that you’re set to accomplish. After kick-off, you should have a solid list of inspiration gathered from the client. This is a good starting point to gain insight into the style, functionality, and feel what the client likes.

Once you’ve established direction, you’ll want to do your research. Starting with the end in mind, take some time to understand what the problem is from your client’s perspective and the user’s perspective. Only after you’ve done research and gathered inspiration can you begin to design a style guide or component library.

On the visual side of things, these are both that you engineering team will rely on for assets during front end implementation. Really, wireframing is where the fun begins. Whether it’s lo-fi or hi-fi, you’ll start putting a face things. From wires, you might even put together a clickable prototype, which can be tedious, but is infinitely helpful as a client demo and as a reference point for your engineers.

Needless to say, iterating is is a key component of the design process. No one is perfect the first time around, even if the client says so! Sometimes clients provide inspiration and direction, but it’s your job to bring those visuals to life. It can be frustrating, but it’s all part of the process. This requires a lot of “This is what I hear you’re liking/wanting and this is how I’ve presented this for you”. The design process requires a lot of communication and back and forth.

Development

There are dozens of languages, platforms, CMS’s, and frameworks to work within. The one consistency in the development phase is starting with a 1000 foot view before drilling down into the specifics. Software engineers have a completely different perspective when looking at projects. In addition to the many ways your code could be written, you have the backend, frontend, and the integration between the two.

Many of my backend engineers say the key to backend is “testing, testing, testing”. It’s extremely pertinent to know what the heck you’re building before you start building anything. Just like building a house, you need to know what features you’re accommodating. You’d take a totally different approach if building a two-story. 1,800 craftsman completely versus a single-story 1,100 rambler.

Get a comprehensive feature set, GET YOUR DATA, and then break it down into digestible chunks. When you’re manipulating data, you need to have a solid overview of what that data’s function is and how you’re going to need it to respond. Each feature being built out will have it’s own subtasks associated with it, so map it out. Use your project tracking software to create a list of all subtasks associated with the feature so you can easily track what’s getting done and what’s left!

On the front end, it’s equally critical to have a comprehensive overview of the product being built. However, the front end team is who is taking those design specs and integrating them with the code. Having rock solid wires, prototypes, and design assets is crucial! This is where having a strong understand of UI is helpful so the front end engineers can hook it up and make it move.

QA

Personally, I think this part is fun! You get to comb through every page, every link, every aspect ratio and create massive list of To-Do’s for your designers and engineers. This is where you’re purposely seeking out the bugs and bringing the polish.

Launch

It’s time to celebrate! Hopefully you have enough energy to celebrate, that is. Leading up to launch can sometimes be stressful and often you’ll see your team make some final pushes with a few big weeks. Don’t celebrate too early, since many last second things can pop up once you actually do go live, but hopefully you have a cushion of time to suss out any major issues before presenting to the masses.

Maintenance or next steps

You’ve finally launched. Now what? Well, if you ended up hating your experience with the client, you can wish them the best and move along to the next one. If you did enjoy working with your client, this is where you can propose an ongoing retainer agreement or a new SOW to begin building out the features or delighters that were pushed off during the initial build. Ideally, your client will tell all their friends how much they enjoyed working with you/your agency and you’ll be inundated with new work requests.