How a Small Startup Should Look Like..?
Recently I went through Product Leadership, a book consisting of interviews of makers from successful startups about their endeavours of nurturing a startup and the journeys thereafter. I thought to share the key highlights of the book briefly along with my own thoughts and experiences being in a startup. The book is more specifically about the leadership/management roles but I think it applies to every maker in a team of small startup.
There is no one right way to build great products; but there is a right mentality and approach.
Enterprise Vs Startup
At enterprise level, product managers are well defined roles and are essential contributors at the intersection of business, technology, and user experience. Its like they are the go to person for every details and insights about the product, be it about design, marketing or technical progress on it whereas in startups everyone has insights and detailed knowledge of the progress about the software or product just because they are all working together on every feature or at least discussing it beforehand.
In startups, technical product roles are well described and documented, while leadership roles remain fuzzy and ill defined. You don’t need a manager for a small group which is innovating, collaborating and working alongside. Everyone could take turns, put their ideas forward, discuss the possibilities and act as a product leader while his/her problems are being discussed.
At enterprise, product leaders have more relevance because they are increasingly the people responsible for connecting the dots between the executive vision and the practical work on the ground. A product leader needs to balance the aspects of viability, feasibility, and usability. To do this, they look to the executive to handle the viability aspect and then translate that into what’s feasible and usable. In startups, there’s no executive vision, its like collective vision of the team and to accomplish that everyone in the team works together from the very baseline.
Programmers make the core of the software products, so it makes sense that they should manage the product teams. We don’t believe the ideal product manager has a specific background or education, but we do see similarities in successful product leaders. Domain-specific skills aside, product leadership is more about leading people and less about pushing pixels, writing code, or administering project schedules.
Product leaders often wear several hats. This is particularly true of smaller companies and startups. In startups, each maker does several other tasks which are not his domain specific. At AltCampus, we have similar scenario wherein we handle social media marketing, user interaction and numerous registrations even though we are developers and training students at core.
A lot of our identity is tied to our work and our skill sets. We work for years, if not decades, honing those skills, so when we’re moved to a position that no longer pays these skills much attention, it can be annoying. Suddenly being thrust into a position that requires a new set of skills can push us out of our comfort zone and make us feel somewhat vulnerable.
These are not forced, think of it as extra responsibilities which comes along with starting a startup.
According to facts, humans do well in situations where there is a clear description of the future they are headed toward. This natural behaviour translates to product visions. Aligning the team’s daily activities with that vision allows your team to connect the dots and see the path ahead more clearly.
Roadmaps are not simply a piece of paper with bunch of dates.
The role of the roadmap is to illustrate our vision of where we’re going. It provides us directions at times of difficulties or diversions.
Product is not simply a set of features; it’s the way that you acquire customers, the sales process that you go through to actually close a customer, the experience that someone has when they’re going through that process. That’s all part of the product, at least in the customer’s mind.
The real cost of a feature is not what it cost in design, engineering, product, and all the other functions it requires. The real cost is once it’s been built and is in production. That’s where you start to see the real cost, because now you have something that can break. Everything that’s built on top of that feature is something that will have to be taken into account. So, in fact, the real cost happens after you ship.
Fixing a software problem after deployment costs 100x as much as fixing it before development starts.
Prioritising roadmaps without market research is the biggest mistake or challenge faced by startups and smaller companies, followed by being stretched too thin, hiring and developing talent, and aligning strategy.
What’s missing is a logical step-by-step approach of answering the long list of questions the team has about the product before coding anything.
Focus on the why?
There’s no point in building a feature if you don’t know why you’re building it. You will always have a thousand ideas for what to build, but where does that lead to? What is the purpose of what we’re trying to do? How does this tie to our company goals? Research, gather data, and prototype until you understand the problem and can articulate a solution clearly and without doubt.
Why, How and What is the solution for each idea you encounter. If you are able to answer them without applying much pressure to your brain, you are good to go and implement it further.
Teams are made up of individuals who each bring their own personalities, perspectives, and opinions. The best team members understand this and embrace the diversity, investing in getting to know one another. Understanding what makes people tick makes it easier to get the best out of them and identify when there is a problem. It has the added benefit of opening up communication channels.
Treat your peers and coworkers as co-creators, and respect the fact that each person is able to bring something to the table based on their area of expertise and their own view of the world. Be mindful that diverse teams may share the same goals, but they speak different languages. More brains produces more ideas and better solutions.
Recently I went through an article which emphasised on necessity of a global mode of communication. According to it, humanity’s desire to create a language that goes beyond mere words is not entirely new in its conception, but the technology available to us today makes it a real possibility.
It is titled..
Emoji: The World’s First Global Language
In almost every human interaction, language is more important than anything else. Cultural and skill differences are quickly overcome when everyone is speaking the same language. If you don’t have a communication framework or tools within your team, you aren’t allowing communication to happen correctly. By having a singular source for vision, the team can march to the same drumbeat.
Listening carefully is the best way to learn something new. Consciously making the time to listen is a skill we could all be better at. Here are some easy ways to improve listening skills:
• Start any conversation with the intention to listen, and wherever possible, the commitment to be the last to speak.
• When someone has made an observation, provided feedback, or simply thought out loud, invite them to “tell me more?”
• When you receive feedback that is suggesting a feature update or addition, respond by asking, “And how would you do that?” or “Show me how you would do that?”
Building trust starts with making something together.Start small if you have to and then scale up as the trust is secured.
A culture where it’s OK for anyone on the team to say, “I don’t know, but I will find out,” nurtures responsibility and maturity, and is a far better strategy than pretending to be a human search engine.
Accepting where you fit in help others understand you better and even provides you direction to go forward. It’s also useful to learn from those who’ve had to overcome similar frustrations and build on one another’s success.
Being punctual makes you more trustworthy and even teaches a lesson to others in the team.
Think positive as there’s a bit of good in everything, even the worst teaches us few important things.
Try to keep the learner’s mindset every time you get to know something new as if you were always ready for it. There’s always things to learn if you are open and willing to learn.
Try to find solution for problems you encounter instead of repeatedly complaining about it. Try another time or try another way. There are numerous ways to do things differently.
The work that individuals in a startup team do isn’t always in agreement with the collective vision, the customer’s needs, and the team’s abilities. Getting everyone on the same page is key to successful teams or startups.
It is not about individual success, it’s about getting the best out of everyone in the team.The focus here is about making the entire team look good. It’s about the results that you can create with and through others.
There is no magical process that is going to solve all the challenges teams face every day, but by embracing change, you set your team up with the flexibility to succeed, no matter what gets thrown at you.
If you’r a team of makers, your day will be judged by how well you stay away from distractions and what you were able to make. No longer are you barking orders at fellow teammates; rather, you’r empathetically motivating creative personalities toward mutually rewarding goals.You need to be like an advocate, coach, guide, mentor, and cheerleader to other team members.
The assumption of authority isn’t guaranteed for good teams. Great team lead by influence and setting example. Leadership is now earned through positive behaviour.
You need to gain authority through your actions and your leadership skills, not your role.This is very different from previous generations, when the manager held authority over the team and decisions by virtue of the title.
Telling your team what you don’t want from them, or that the product might fail if they do a certain thing, is the incorrect way to motivate them. Great teams do not use negative expectations to motivate their members.
Failure should not be used as a threat because it is part of the game, and needs to be taken into account. Failure that happens because teams are experimenting, learning, and pushing the limits is normal and should be expected.
Using the threat of failure discourages people from doing the experimentation necessary to find solutions.
While the technological landscape is rapidly changing , its time for modern startups to think outside the box and do not get stuck in the legacy management systems for their services or products to flourish.