My blueprint to launch a tech product

Through the years, I’ve worked on multiple products, in a lot of fields and I want to share with you my blueprint to launch a tech product. I won’t say successfully or that this is the only, right way to do it, I just want to share my experience.

So here we go.

Defining a product person

Dedicate someone in charge of the product. This doesn’t mean he gets to decide what’s being developed; what it means is that he needs to be responsible for making sure that the team meets the goals of the development cycle and that what we build is what was envisioned.

Release cycle

There are 2 perspectives that you need to look at when you think about releasing a product: web release cycle and mobile release cycle.

Web release cycle can happen every day if you want, but it is not recommended. the industry standard — let’s call it that — is a 2 weeks release cycle. This is mostly because Agile methodology is the leader of this standard. In these 2 weeks usually, you can get enough done and also tested, so you can release a new version, even if it’s just a release that contains only bug fixes. 2 big takeaways here are: do not deploy on Friday and make sure you do code freeze at least 1, 2 days before publishing the new version.

Mobile release cycle has some dependencies, given by app stores: Android and iOS, Apple usually takes some time to put your app into store; depending on the app size and complexity it can take up to 7 days, so you need to make sure that you test the app very well before you deploy it into the app store. If you want to publish an update and your app is in the queue for review, you will get a reset and get back at the final of the queue.

KPI

Every product team should establish their KPIs; not too many, try to keep it simple to be able to create small goals out of them, so you can see improvement. Reaching small goals is what keeps your team and yourself motivated.

If you are a small team, try to involve all the people into the idea process, where you establish your next goal and involve everyone into bringing up ideas on how to reach that goal. After you all express your ideas, try to extract from there the features/processes that you need to put in place to achieve that goal.

Now, because it is very hard for a product team to focus on everything, you need to PRIORITIZE. The hard part is that you need to choose from a set of ideas, some of them may be very hard to implement but very powerful, so how can you decide what to start working on? should try to prioritize by necessity.

At first, it will look like you need everything to succeed to reach the goal and you can not say that this feature is more important than the other one. But believe me, you need to do it, you need to analyze and see what should come next — giving points of hardness to the features is what we used a lot in the products I and my team developed through the years.

For the hard features, it’s better to establish 2 types of approaches: short term approach and long term approach. The short term approach usually involves using a 3rd party API or more like a hacky solution, that is enough for you to test out the feature and see if it’s worth investing more into it. The long term approach usually means the fully-functional feature, built in-house. That should be put into the backlog and referred back to it when the prioritization cycle comes to it.

Estimations

Estimation is a nightmare for every team, it is very hard to prioritize unknown. But you need to do it anyway, so try to give a rough estimate on what a certain feature/process will take to accomplish. In 99% of the cases, the approximations are wrong, you’ll probably be very optimistic — but the goal is basically to try to give, as much as you can, an accurate estimation. When you do estimations, you will miss the exact date by far usually but what is important is that as soon as you discover that the approximation is wrong, you should bring that up to the team and try to see how far off you were and what you can do to not miss the deadline by a long shot.

QA

Everyone needs to do QA at the beginning when the team is small, of course. If you have some budget, a QA person is very helpful from various reasons: a developer is not the right person to test the product, the developer mind helps but not when you test the product you worked on because testing from a developer perspective won’t catch a lot of bugs like the UX bugs/flow bugs.

The QA person needs to think as a user, needs to test the flows defined but also test the flows as a non-tech person. This is something that every developer is struggling to understand. We use technology all day and some processes seem so flawless for tech savvies — like swiping left or right on a mobile when you are into a gallery with pictures. Someone non-tech does not have this behavior developed into the unconsciousness, so he might not figure out how to do it if the flow is not specific enough. The tech mind can not think at workflows that a non-tech mind thinks of. Of course, this also depends on what kind of product you develop — if you are developing for developers as a target audience, you might not consider these issues.

And finally: celebrate small successes. Motivation is what makes your team give everything they can to succeed. The right type of leadership is one of the characteristics that make a team to deliver success and not a failure.

Keep building!