Interview: Technological Startups

I was interviewed recently about challenges and recommendations for Technological Startups. Although the interview is in Spanish, I share with you the written translation of the interview in English. Also, the video may include English and Spanish subtitles if you like.

Click to watch the interview

Good morning Alejandro, On this occasion and taking advantage of your experience as an advisor to technology startups, we would like you to tell us a little about the challenges that a startup of this type faces.

A technology startup faces multiple challenges. Perhaps the most important of all is to understand the customer and the market, but there are of course many other challenges, such as identifying the right product or service, knowing how to shape and industrialize it, finding investment, correctly designing and executing the marketing and sales strategy, or just grow.

Could you give us some guidelines that a technology startup should take into account in its first steps?

The Market

The first thing is to select the market in which to operate. It has to be interesting, fun, and motivating for entrepreneurs.

You need to know the sector and the client very well. Do it first-hand, not just from third-party reports.

It is also necessary to take into account cultural, idiomatic, usability aspects, barriers, competitors, regulatory aspects, registered patents, etc.

The Product

On the other hand, there is the product or service. This must be focused on the client and their needs. In many cases, the form of the product is more important, that is, the contribution of value that the customer perceives from the product than the product itself.

It is recommended to start with a minimum viable product. In other words, to get basic results with the minimum investment in time and cost, that allow the product or service to be tested in the target market.

Sometimes the entrepreneur focuses on making a product with a very high technological contribution, investing too much time with its associated opportunity cost, when the priority may be to verify if the market is really willing to pay for that product or functionality.

One of the techniques that is usually recommended is that of "validated learning", which consists of testing assumptions about the interest of customers, aspects that we believe are important to them and perhaps not, and measuring our progress in some way, not by the sales made, but through learning, which is what brings us closer to finding what meets the customer's need or desire.

When Thomas Edison invented the light bulb, it did not work out the first time, but he made more than a thousand attempts, to the point that one of his collaborators asked him why he persisted in building a light bulb if after more than 1000 attempts he had not succeeded. Edison replied: They are not failures, I learned 1000 ways of how not to make a light bulb.

But you also have to know how to make the decision to persevere or pivot your strategy.

Escalability

The product or service must be scalable, that is, if it is successful, scale factors can be applied, such as offering more units to cover the market, creating accessories or adding functionalities.

There must be a multiplier factor that turns the startup into a money-making machine when the time is right.

Business Plan

A good business plan is a roadmap. You have to be honest and consider alternatives.

The plan must analyze all the critical aspects of the business: the market, the value proposition, the team, the marketing and sales plan, the growth plan, the financial plan,... and of course a Plan B in case things do not go as expected.

Financing

To obtain financing, a startup can go through crowdfunding processes, search for business angels, and many other investment models, but in order to access this investment, the business model must be prepared very well, demonstrate that the idea has passed a certain validation of the market, that it is scalable and that the correct team is available, not only technical but also experienced advisors who mentor and accompany the company not only in its initial start-up but also during its journey and growth.

We already know the Chinese proverb: "If you want to go fast go alone. If you want to go far go together".

AMR-One. 01 Product Strategy and Roadmap

This is the first on a set of posts about the project AMR-One. 

AMR-One Project's scope is the development of an autonomous mobile robot for the industry. The set of posts covers not only the technical part but also project management and strategic concepts.

In this post we will mention the strategic part of the product, talking about the Product Strategy and Product Roadmap.

A Product Strategy is a high-level plan that defines your product goals throughout its life cycle and how it will support the organization’s goals. The product strategy will also answer who the product will serve and how it will benefit them.

These plans are then brought to life on the roadmap.

A Product Roadmap is a plan of action for how a product or solution will evolve over time. Product owners use roadmaps to outline future product functionality and when new features will be released.

To build a roadmap, product owners should consider market trajectories, customer value propositions, strategic goals, and effort constraints. Once these factors are understood, the product owner can work with their team to start prioritizing initiatives and epics on the roadmap.

The roadmap should be updated as often as necessary so that it can remain an accurate source of truth.

Having that roadmap we should go ahead with the Product Lifecycle Management, which is the process of managing the entire lifecycle of a product from its inception through the engineering, design, and manufacture, as well as the service and disposal of manufactured products.

See my previous post: 5 tips on ... Product Strategy & Product Roadmap

See the following video on how these concepts are applied to the AMR-One project:

The Project Management Plan

[3 minutes reading]

The Project Management Plan is defined as the document that describes how the project will be executed, monitored, controlled, and closed. In my previous post I explained the early steps before preparing it. 

I would say that one of the most important keys to preparing a good Project Management Plan is to understand why this document is needed and how it could really help the success of the project. 

This document, as mentioned at the top of this post, describes the rules for the execution of the project. We need to understand that in a project there might be many people involved and many phases to execute. It is key to have a common point of understanding of the rules for the management of the project, so anyone could read them when needed. Rules could change of course, but always under some kind of control.

Source: PM illustrated

The Project Management Plan could include the following important sections and components:

• Scope management plan. Establishes how the scope will be defined, developed, monitored, controlled, and validated.
• Scope baseline. The scope baseline provides the project and product definition.
• Requirements management plan. Establishes how the requirements will be analyzed, documented, and managed.
• Project life cycle description. The project life cycle determines the series of phases that a project passes through from its inception to the end of the project.
• Development approach. The development approach defines whether waterfall, iterative, adaptive, agile or a hybrid development approach will be used.
• Schedule management plan. Establishes the criteria and the activities for developing, monitoring, and controlling the schedule.
• Schedule baseline. The schedule baseline is used to assess the impact of the changes in the project schedule.
• Cost management plan. Establishes how the costs will be planned, structured, and controlled.
• Cost baseline. The cost baseline is used to assess the impact of the changes to the project cost.
• Quality management plan. Establishes how an organization's quality policies, methodologies, and standards will be implemented in the project.
• Resource management plan. Provides guidance on how project resources should be categorized, allocated, managed, and released.
• Communications management plan. Establishes how, when, and by whom information about the project will be administered and disseminated.
• Risk management plan. Establishes how the risk management activities will be structured and performed. 
• Procurement management plan. Establishes how the project team will acquire goods and services from outside of the performing organization.
• Stakeholder engagement plan. Establishes how stakeholders will be engaged in project decisions and execution, according to their needs, interests, and impact.
• Change management plan. Describes how the change requests throughout the project will be formally authorized and incorporated.

Not all these sections are mandatory. Of course, tailoring practice depends on the kind of project and complexity, company culture, and other factors. But in general, I consider it good practice to have all of these sections included as they cover most of the key important aspects of a project. 

---

Bibliography:

• PMBOK
• Before starting a Project

Before starting a Project

[3 minutes reading]

So you have a nice corporate Products Roadmap (see my previous post 5 tips on ... Product Strategy & Product Roadmap) that includes the products that will help your business succeed. Now let’s start with its execution, step by step.  

These steps are defined in the phases that compose the project life cycle (not the product life cycle). In this case, I will consider how PMBOK groups these phases. 

There are some initial steps that are quite common in all kinds of projects, even if they use Linear Process models or Iterative Process models (see my previous post 7 tips to choose a Methodology for Software Development): 

Source: Project Management Body of Knowledge (PMBOK) seventh edition

Pre-Project Work

This phase is where we should evaluate in some detail the real business need of the project and the estimation of the costs through the preparation of the Business Case document. It might be a very detailed study or just something simple and quick depending on the project, but is something key to work on. It is not uncommon to find companies that jump from the corporate Products Roadmap (if they even have one) to the project execution, and this directs them to big holes of investment in projects with no clear ROI.  

A Needs Assessment often precedes the Business Case. The Needs Assessment involves understanding business goals and objectives, issues, and opportunities and recommending proposals to address them. 

The project Benefits Management Plan is the document that describes how and when the benefits of the project will be delivered and describe the mechanisms that should be in place to measure those benefits.

Starting the Project

So we have this Business Case that gives us some understanding of where we are investing the money from the company. Well, the next step is to prepare a Project Charter. This is a formal summarized document that includes the following information:

• Project purpose;
• Measurable project objectives and related success criteria;
• High-level requirements;
• High-level project description, boundaries, and key deliverables;
• Overall project risk;
• Summary milestone schedule;
• Preapproved financial resources;
• Key stakeholder list;
• Assigned project manager, responsibility, and authority level; and
• Name and authority of the sponsor or other person(s) authorizing the project charter. 

This document is approved by the Project Sponsor and when it is signed, gives the Project Manager full authority to start the project. 

Many people see this document as “another boring document that the bureaucracy of the company demands” but this is not at all that. It is a key document to understand the whole key elements of the project from the management standpoint. Without it, management might take decisions without enough global vision of the project.

Once the Project Charter is approved I recommend going ahead with a kickoff meeting. It is the first meeting with the customer or sponsor and the project team, to give a vision of the project. Many companies do not pay enough attention to this meeting, but it is crucial for the success of the project as we will involve the team in the project from the beginning. This will help identify risks and help in the planning process.

Organizing and preparing

Here is where the Project Management Plan is prepared. The project management plan is defined as the document that describes how the project will be executed, monitored, controlled, and closed. It includes all the rules of the game of running a specific project, including the methodology we would like to follow.

This part is so important that I will dedicate my next post to this subject, so I see you then!

---

Bibliography:

• PMBOK
• 7 tips to choose a Methodology for Software Development

5 tips on ... Product Strategy & Product Roadmap

[5 minutes reading]

Product Strategy defines what your product should achieve and how that supports the organization, and is brought to life through the product roadmap.

A Product Roadmap is a high-level summary that shows the vision and direction of your product offering over time. It is a key strategic document as well as a plan for executing the product strategy.

Clearly, both are key for a product-focused company, and many books, posts, videos, courses talk about it. Here I will just share with you a few key tips that I learned from my professional experience in the software and automation business. I wish these tips will help you to get a successful business.

Tip 1. Product strategy and roadmap should support market needs. It is sooooo common, especially for small companies, to focus on what they want to do and not what the market wants to use and pay for! This is a very common mistake and might put at risk the survival of the company. Recommendation: Base your decisions on market analysis, conversations with customers, demo prototypes, proofs of concept, or even sales experts' gut feelings, but consider the customer needs, not your desires.

Tip 2. Your customer is your mate. Many companies just see customers as the people or companies that pay for their products, but customers should be seen as colleagues, mates to ensure we build a win-win relationship with them. Otherwise, customers will come and go, because they will see you in the same way, as the supplier of something they just need at that moment. Recommendation: Work with the customers in the definition of your roadmap, not just getting their inputs, but involving them in an evolving adventure to have products that will help them as well as you. 

Tip 3. A roadmap might be flexible, but not too much. A Roadmap is a guide for the whole company. It might be used by the sales department to advance future products to the customers, or by the development team to plan resources, or by the finance department to prepare treasury plans. Some companies tend to adapt the roadmap depending on the commercial opportunities and customers. Roadmaps should have some flexibility to adapt to changing circumstances, but too many changes produce confusion in the organization. Recommendation: Define a Roadmap. September is an adequate moment, so resources could be allocated for the new year, although any time of the year is good if you do not have one. Once you have that roadmap, evaluate the risks and impact of any change you might want to do before applying it. 

Tip 4. Pay attention to the cost of building a product. Many companies consider that a product costs what it is needed to make it in terms of time and resources, but it is not. There are many other costs related to a product that should be considered from the beginning, like integration testing phases, standardization and industrialization, proofs-of-concept (POC) with customers, documentation, rules compliance (like CE, etc), demos, internal training, and something that many times is not considered: Maintenance. Because there might be bugs, improvements, design mistakes that will need time and resources, especially in a new product launch. Recommendation: Plan considering all the phases of a product life cycle, not only on the few first ones. 

Tip 5. Give a good product or you will lose the good customer. Quality, quality, quality. This should be a must in any product and many times is not so. The rush to have a product in the market means many times reductions in the validation and industrialization phases. Recommendation: I know it is a trade-off not always easy to solve. The key is to take a strategic decision, planning in advance the time and resources to ensure the product is good enough for the market. Be agile in the execution and reduce functionalities if needed, but not reliability.

As you could understand, product strategy and product roadmap are very serious strategic decisions. Good practices will not always ensure success, but bad practices will definitely make the company fail. So let’s pay full attention to do it well.

I recommend reading this post: What is the key to get a successful product?