Setting up a Production — an Overview

Thinking about the very first moment of a product might seem trivial. Someone gives out a task and you make a product out of that — so what? Let’s call that whole thing a “project” and this post is done.
 From experience you might know that it is rarely this simple.

Here, you will hopefully get some food for thought on what a fresh production needs from the product manager to hit the ground running. You’ll get an idea on which questions to ask and which decisions to (not) make the next time you’re involved in starting a new product.

Before Production Begins

Usually, there are two paths to a new product:

  • An idea got pitched and in some way greenlit — now the idea is to be made into a product
  • A business goal or partnership arose which now needs a product to be achieved

Imagine that this step was taken. You now have a something which describes the goal or briefing (a oneliner, a deck, a contract and so on). This is the starting point of your product.

Now it’s time to fill in the blanks. Often, some of the information needed to fully start you already have — but what you want is to answer all of the following questions as good as possible before proceeding:

Figure out for Whom

“Target audience”, “end-user” and “customer” are all phrases you hear day in day out — and all of them mean nothing on their own. Without an idea on who your audience is and what they need, it will be very hard to have fruitful discussions or a user-centric production. Target audience assumptions should be based on what you already know or what you can confirm. In general, you want to use all the information you can get. When thinking about your audience, the information you gather usually fits within two categories:

  • Statistical based descriptions are best used to describe the reach of your product. This approach is useful if you try to solve a very broad issue. You can gather this data based on similar products. An example would be: 64% female, main age cohort: 43–47, avg mobile session length 45 min, 9 sessions per week.
  • Behavior based descriptions are best used to explain how your product impacts its target audience. You can gather this data via surveys, studies or through observation. An example for this would be: “People who are using the train have YouTube videos running without looking or turning off their device”.

In reality, it doesn’t matter as much on how you describe the audience. Fitting all this data into a persona will allow you to talk about your target audience as a single person and help others understand whom you try to reach. An empirical, numbers based descriptions allows for a more balanced discussion. You can put a check on the “who” question as soon as you can easily describe to three different people: Your CEO, an external user researcher and a junior developer.

There’s a catch though: Answering this question will remove a lot of (political) freedom within your environment. It’s harder for your CFO to seel your reach of 110 million people if you clearly show that you have a target audience consisting out of 15 mio max. It’s a good idea to check which impact your findings have. It’s also a good idea to check if something within your production should be changed to react to your findings.

Figure out Why

You read it all the time: “What is the need you want to fulfil?” or a different phrasing of the same thing. The reason this is mentioned everywhere is simple: It is one of the most useful questions for you to answer throughout the whole production. Not only does the answer allow you to challenge the roadmap and single features early on, it will allow you to explain the product on all levels:

  • For an end-user, you can show the benefit (“You will get your job done in half of the time!”)
  • For the sponsor, you can explain your decisions (“We can increase ease of use by doing X, allowing users to perform their tasks faster. Feature Y only has the benefit of being a bit nicer looking, so I chose X”).
  • For the investor, you have an easier time talking about money (“With this many users saving time, you increase your reach and overall conversion. The expected impact will have direct business implications.”)

A note on forecasts: Always under-sell to people who will spend (or plan with) money which your product is supposed to earn purely based on your forecast. When working on a new product, most figures are ranges. The more a person or department has to work with your figures in this moment, the more conservative your forecast should become. Figures are way too often read as facts and you won’t always be able to prevent this. Treat them accordingly and put a HAZMAT label on them.

Keep in mind: What happens with your predictions after you communicate them is out of your control. Staying realistic (or even conservative) at this early time will lower negative impacts from wrong expectations from your sponsors and users. You can make life easier for future-you by managing expectations early on.

Figure out What

At the top of this post I told you that the product begins with an idea or a briefing — which translates to “what”. Now is a good time to look at this “what” again and check: Does it fullfil the “why”? Does it potentially reach the “who”?

If both of those answers are yes, awesome. If one of those questions is answered with “no” (or, more realistically, an “uhm”) then awesome as well — you are now in a position to prevent building a product based on wrong assumptions. And no matter what your findings are: It’s a good idea to run them through your sponsors (and team, if already existing).

Sometimes, you don’t have a high level description (e.g. a Vision). Now is a good time then to take your insights into the “why” and the “whom” and sit down and create a brief vision. There are two groups of people which I can higly advice you to involve: Your stakeholders and your development team. Both groups have a lot of impact on quality and velocity of your production cycle. Involving them when you shape the “what” will make your life easier down the road. Your teams involvment will reduce context questions and transfer ownership. Sponsor involvement will increase acceptance and alignment.

So … What’s Next?

Now that you have an idea of what you build for whom — and why. Now all you need to start is the “how”. It is now time to look at the other factors which you need to start your production:

  • What are the limitations you are working with? (e.g. timeframe, sponsor-interests, competitors, legal requirements, technology, …)
  • What resources do you have at your disposal? (e.g. do you have a team already? Can you outsource? What’s your budget? …)
  • What framework or setup will you use to develop? (e.g. Scrum, freestyle lean, Kanban, Waterfall, … — even the decision to not use a framework or system should be made consciously)

Once you have your starting set of information and decisions you can move forward. It is time to finally start. You have everything that is needed to dive into the requirements management, to create a backlog, hire a development team or whatever it is that is missing from entering the product development cycle.

One last thought: This set of questions is neither complete — nor should your answers be final. You will learn new things on your way throughout the development — embrace it and integrate it into the answers you gave in the beginning. Then check if those changes need a change in production and react accordingly. A good preparation is invaluable for your production — just keep in mind that this was the easy part! Truly successful products are millions to one. But:

“Scientists have calculated that the chances of something so patently absurd actually existing are millions to one. But magicians have calculated that million-to-one chances crop up nine times out of ten.”
 ―Terry Pratchett, Mort

Originally published at Timeboxed.