You’re a Product Owner of some business you plan to expand more. Great, you’re an aspirer now in search of an executor. In your case it’s a Project team that can start it rolling.
Drinking cocktails while developers finalize the project is a dream that will hardly come true. You can, of course, prefer path of less resistance and choose scrum mode of interaction. But in such case you will have strong chance for vague deadlines and functionalities of your Tech partner as you give him no time to plunge into your project.
If you really want to test your idea’s viability you’ll need to have it estimated, calculate its possible budget and choose the team for implementing it. As with a quarrel it also takes two to make a project: a Product Owner and a Tech partner. Let’s see what must be done to turn any possible quarrels into quorums.
Product Owner’s part:
First it’s you who needs to have сlear vision of your future project.
Next, you need to deliver this knowledge to those who’ll put it into life. Common mistake is expecting the Tech partner’s team to read your mind. No mediums here, alás. Nobody will give you any estimates at this stage. So, don’t run before you walk.
Businesswise it means you should create a team from different departments within your company. Each department will have to supply you with
for project developers to meet. We especially need them in e-commerce field when an offline retailer wants to progress online. In such case we won’t go without:
1. Description of the product
Great if you have any technical specifications. If no, just describe it and tell what problems you expect it to solve for your clients.
2. Customer journey of your client
- who he is;
- which channels he comes from;
- his points of interaction with you;
- his behavior patterns;
- any bottlenecks he’s experiencing;
Format of business requirements doesn’t really matter. It can be presentation or just a list sent by email.
For example, if you have a parking service you must know that the main pain of your users is frustration when they don’t know whether there are vacant parking spots. You can solve it by offering them an application showing any vacant spaces in advance and moreover offering to pay for them by card.
What is your point of interaction with them? They enter the application, choose the parking spot and pay for it. What problems do you help to solve? You spare your customers’ nerves and save their time. That’s what you must know before you start your project: why you’re doing it, what problems do you help to solve and how it must look like to realize all that.
3. Monetization model of your project
Now we know what the customer is doing, why and how to help him. Next step is to define your monetization model of the project. What you can earn and how. Sometimes, especially in e-commerce it can be demonstrated avoiding complex tables. You can just explain that attraction costs and sales made online are 3 times cheaper than offline so margin will grow from 30% up to 45% and that will be enough to understand how it works.
This stage is also very important for imagining what kind of UX you’ll have in future. As this UX is a powerful tool of your influence upon your users. For instance if a business owner is interested in purchases of $100,00 and more there must be deployed all user’s experience to make your customer fill his cart up to $100,00 an achieve it by offering free delivery or some give-away or bonus.
4. Enlisting specifications and limitations of the project:
- integration specifications, which means that Product Owner describes what must be integrated with what;
- delivery terms limitations;
- budget limitations (approximate amount planned for investment in the project);
5. Version release planning:
It’s more seen abroad as they’re used to launching the product the soonest possible to test hypothesis and try to get the slightest revenue.
In our country we prefer polishing the product until we ensure the Bentley’s quality. Still it would be wiser to start the soonest, interact with final customer to see the feedback and test hypothesis cheaply before launching the final version of the project.
Tech partner usually requires information as to how big the product will be, what functionality it will have and how the Product Owner sees its first, second and next versions if needed.
6. Prioritizing your requirements:
Both your team and the Tech partner’s team must know which things go first. It will help you to concentrate on most important tasks keeping an eye on less urgent ones.
Tech partner’s part:
Having provided all information from his part, what can Product Owner expect?
Plunge into your project
A professional Tech partner will do his best to get to know your project as if it was his own. You can see it if he requires all the above information from you. If he just asks for a list of features to stuff your project with, run.
You can also test it by organizing an online or offline meeting with a Tech partner and ask him to describe your product or project to you. Thus you will have an idea whether your views coincide.
After you’ve set you’re on the same page it’s time for the Tech partner to demonstrate what steps he’s going to take to realize your project.
Taking into account all delivery terms, budget and integration specifications, he can decide whether he’s going to use in-house resources or apply to some outsource teams.
Specified architecture of the project
Within the frames of use-cases the Tech partner is developing the architecture of infrastructure and database of the project and the architecture of the application itself (its component system (micro-services and other).
Detailed work breakdown structure
Experienced Tech partner can make one step forward and offer you to break down the work under your project into modules. Each module will have a fixed price. It will give you the freedom of operating your project and costs according to your budget. Besides, it can help you assess the risks and ways of solving them. It’s not a free service and usually it’s a step towards more profound analysis of price for your project.
In our company we offer wire-framing, that is schematic conceptualizing of all skins, log-ins and their interaction in application, which is schematic UX. That is in our case we offer well-thought use-case together with description of all your use-cases, for example MVP according to his project.
Why would you need it? You will have all documentation which can be realized by any team in case the Contractor lets you down.
What about Agile?
There is flexibility of course. But any business has some limitations both in budget and delivery terms. Any project requires analysis. If you choose the agile way there is no space for prior assessment.
If you choose the iteration way, then you just need to know the rates per hour of your Tech partner’s team.
But if you decide to make a really good product, prepare for a tough play. Leave no space for misunderstanding. The more details you discuss the more precise your project will be. Fight for every nuance and remember to keep your Tech partner closer. “Thought thrives in conflict”. It’s the same with projects. Only together you can assess if it really worthwhile. And if yes, you’ll already have a good teammate by your side.
After project estimation the most fascinating part begins. Take a look at out article about bottlenecks of development, and how to make it work smoothly and successfully.