Manage the product & services in a small software startup
This article is part of a series about how to manage a small software start-up, the first article & overview is found here.
Product Management
Stemming from the north star, the solution to the problem found ideally consists of one core product, for which the vision needs to be clearly defined, and all team members need to be aligned. I like the approach called “working backward” used at Amazon, which consists of envisioning a finished product first and write a short press release (1–1.5 pages). This should be a collaborative effort in the founding team, which will be the kickoff of product development, in addition to the use of more strategic tools such as the lean canvas.
This product needs to be built, put in operation, and sold to clients — these tasks not only need to be done but also orchestrated — I like to call this orchestration product management.
We organized all tasks related to the product in one project (more about work management in a later article) with the following functions to be kept aligned:
- Support/Operations (Ops): Very often underestimated effort of the deployment, installation, and maintenance of the product — also collecting feedback on bugs and general usability of the product
- Development (Dev): The actual creation of the software (programming/coding…)
- Design: The looks & feels of the user interface, ideally most features are designed before being implemented (not always possible)
- Marketing: The external presentation of the product, responsible for giving demos and gathering feedback on its appeal — very closely related to sales and business development
In addition to orchestrating these tasks, the product manager was responsible for defining the product’s development roadmap and the detailed technical requirements, such as which browsers and operating systems would be supported. Depending on who you ask, the role can be endlessly expanded — some people consider the pricing, defining the unique value proposition, or competitor analysis as part of the product manager role — I consider this to be part of business development instead.
The development roadmap is simply a timeline defining during which periods what features should be developed. New suggestions for features could always come from any team member and were categorized according to the need the suggestion stem from:
- Project Need: A customer project needs this feature — usually associated with a strict deadline.
- Sales Need: This feature would help us to sell the product more effectively.
- Engineering Need: Helping to reduce the technical debt, i.e. make future development faster or minimize error rates.
Every feature should therefore have a clear need. In addition, we decided that only features doable in a 3 months time scale should be proposed and otherwise split up. The product manager is responsible for sorting and cleaning these feature suggestions before every alignment meeting between all functions. Especially for the sales needs, it’s a good idea to also distinguish between basic needs and delighters (see Kano model).
There are a lot of different combinations one can choose for feature and work iterations; experiment and be inspired by other transparent companies — check for example Basecamp’s approach here.
[W]e never want our roadmap to be just the list of things that people have asked for. That’s where the longer-term thinking comes in. You have to balance the short-term, reactive stuff with the long-term. — Michael Siliski, Stripe
Three remarks on the processes to be set up for product management:
- We found that people naturally will discuss much more about the current state of the product than the vision, don’t forget to regularly align on the vision as well.
- Most teams nowadays follow some variation of agile processes — ironically though, many seem to forget the first sentence of the manifesto for agile software development: “Individuals and interactions over processes and tools”. Don’t forget that in the end, it is all about building a successful product and having a good time on the journey.
- At the beginning of a company, the roles might not have clearly manifested yet, and it’s even difficult to define a short press release — consider organizing more fast-paced design sprints initially. I wouldn’t encourage these as a repeating process, though, as the team will burn out quickly.
Consulting & Services
Even if you are trying to build a product, to truly solve the clients’ needs, you usually need to offer additional services — especially in B2B. Zapier, for example, grew by selling integration services around an unfinished product. It is a good idea to think ahead of time what services might be valuable to complement the product development efforts, as for example:
- Workshops in your area of expertise, especially for larger clients
- Software integrations, e.g. for file sharing, messaging, ERP systems
- Service agreements for guaranteed support
- Specific feature requests (many customers are willing to pay to speed up certain developments!)
- Consulting projects
As mentioned in the introductory article, we decided to grow our company organically by selling consulting services to clients in our target market, pharmaceutical companies. This is definitely a safer route compared to going with investors from the start, especially if you are unsure about your ambitions regarding the eventual potential of your idea. Other advantages include:
- Founders are truly independent and can decide where they want the company to go
- The value of the company increases without the founders being diluted
- Missing market knowledge & skill-sets can be built up in the team
- The problem can be better understood by solving them through hands-on work directly
There are several problems with this strategy, however, that need to be mitigated wisely. Overall it is essential to have clear guidelines on what kind of projects are pursued. Otherwise, only money will be the driver, and you will probably end up in an unhappy situation.
Toxic Billing Culture
For me, it was usually much easier to sell time & material projects than goal-based ones. But if your vision is to build a tight-knit team, I recommend investing energy into getting projects with clear goals where your employees can work as a team from your offices. Otherwise, you might fall into the common pitfalls of a consulting organization (see also this article):
- The employees are the product, and everybody is always concerned with “billability”.
- There won’t be (short-term) incentivizes to build a good culture as everybody is working separately anyhow.
- You are incentivized to spend time rather than doing great work. (See also my friend Manuel’s take here)
- There is less proximity (both space and time) within the team, so it’s difficult to bond.
Losing Focus
Many people will start to see “so many opportunities” the first time they get paid for their work in a new market. It is paramount to focus only on projects that either fuel product development directly or build up more specific expertise in your area. We established the following criteria for every project:
- Familiar technology stack (e.g. Java, C#, React)
- Working as a company to provide working software, not “body leasing” to a customer (see above)
- Application focus, in our case life science automation and scientific instrument integration
- A minimum budget of the project to avoid having many small projects to take our attention
- Depending on resource planning: Sufficient time to prepare for the project if we need more hands (hiring takes time!)
Missing market validation
As you will naturally only solve the problems of the clients you have, you might miss the bigger picture on what the market needs — especially as your early clients might only be of a particular type in terms of region, personality, or hierarchy.
For example, some of your efforts might be funded with some “innovation budget” of your client who just wants to try out some new technology but doesn’t actually have a proper need for your solution.
This is why for successful product development, the consulting revenue will need to cross-finance truly independent product efforts. Even if it sounds unflexible, I think it’s helpful for some team members to be “employed” at a certain percentage of their time to further develop the product (both on the technical and business side). Otherwise, most people will be drawn constantly to consulting projects as that’s where the money comes from. Some activities are hard to finance directly from a customer, such as reducing technical debt or market research.
Separated team
If you decide to have some people focusing more on the consulting part, whereas others focus on product development, it can quickly happen that the team splits apart.
An extra effort is needed to make sure that the consulting team understands where the product is going and how it can help future projects, whereas the product team understands what happens in consulting projects and what can be learned from them.
Additionally, to be able to hire good people working on consulting projects, you have to differentiate the work you offer from other consulting firms with better pay.
In the next article, I write about how to sell the products and services you offer.
