It's good to be ambitious. As an entrepreneur, you should never be without ambition, because it is the only thing that separates you from the average person. If you don't even have a strong ambition, then you are definitely not fit to start a business. But misconceptions do exist and have to be pointed out.
Product should come first, platforming comes after
Many years ago I also wrote programs, and knew some technical cattle, people don't care if the ordinary people will use it, the pursuit is to use the least code, with the most powerful method, the function written out, as for the function itself can help others solve the problem, I don't care at all, because that is the responsibility of the product manager. My brain has to be used in a more meaningful way, like working on newer, dumber technologies.
If the founders don't know anything about technology, and they're looking for a technically skilled person, it's easy to find some "pure" engineers. The problem is that most users don't know what technology is and it doesn't matter to them, and Paul Graham, after decades of writing programs, has come up with an insight: "Don't develop the smart stuff, develop the stuff that people want."
Technology has evolved rapidly over the past decade, with a wealth of publicly available code and tools to help engineers design powerful programs. But over time this has resulted in a situation where people now tend to be more interested in designing clever things, but less focused on developing what users want. It's a product-centric world now, where users don't care if a product is written in C or another language, they just care that it's fast, the interface is clear and intuitive.
To build the best product, you have to know who the user is. It's important to always be aware of the needs of the user and to meet them. Because people's tastes and what's popular are ever-changing and competitive, and it's impossible to create products that keep up with them unless you are attentive to how they change, how they grow and where they are going.
This is where some people wonder - should we have the content first and then the platform, or should we have the platform first and then find the content? It's like getting the production line ready before taking orders, or getting the orders first and then getting the equipment. The answer is simple - no company builds a factory before they know what they are going to produce. And no customer is going to place a valuable order with you without knowing what you are selling. So the point is to find the product that solves the customer's problem, and preferably a pain point, and then it's just a matter of time before orders and production lines are placed.
In other words, building the platform has to come after the killer app. Imagine: if it weren't for the pressing problems of not getting a taxi or refusing a ride, taxi apps wouldn't have become so popular; if it weren't for the breakthrough in the interactive experience of accessing the internet, iPhones wouldn't have been sold in the market. Platforming, all that comes after. As good as the big platform dream is, it's all for naught without the first users brought in by a killer app.
In order to create a killer app, you have to come up with good product features and develop them quickly, test them with a small group of users and collect data. Then, if a new feature improves a key metric (e.g. people use it more often, for longer or spend more), you make it available to all users. If a feature of the product is not working well, it must be adjusted or removed.
The data does not lie and there is not much room for error in this process, unless you are not good at doing this.
Come up with product improvements that can be tested.
Figuring out how to assess the effectiveness of product improvements.
Determining whether the data related to the product features at hand will make the core metrics higher or lower.
What kind of people do early stage teams need?
Transitioning to the internet can be full of fear and imagination of the unknown, and you would want a dream team. In an ideal world you could literally hire these people in the early stages, but in reality, I'm afraid it's going to be meh. So, we can only look at the structure of the ideal team first to make sure the way forward is right, then it's best to start by delving into who can provide the answers to the following three key questions.
1, What product are you developing?
2, Does the product solve a real problem?
3, Who are we solving the problem for (the target user)?
It is unlikely that there will be more than one person on the team dedicated to the product (and ideally, one excellent designer, i.e., two people in total) before the product has been polished to meet the needs of the market. Only when the product is on track will the product team need to be expanded. Products in the taxi category are relatively complex: made up of passengers and drivers, both applications must work simultaneously to reach the stage where the product meets market demand, so the amount of development required is higher. If the application is not complex, then only one product manager is needed, and the rest of the money is better spent on hiring engineers first, to focus fully on developing better technology for the company. The bottleneck that can be encountered during this period is usually not a lack of ideas for product features (yes, there are often too many ideas), but how quickly users can use all the product features.
During the development process, other questions usually pop up, such as: How does this app look? How does this app work? ...... It is the design team (often part of the product team) that is responsible for answering these questions. It may be true that you only have the budget to hire a designer (sometimes on a part-time basis), but in order to deliver a killer product you have to work more closely with the designer.
All product people are really answering the "what to develop" question, and some teams divide into product managers, designers, UX specialists and so on, which is really boring and pointless for early teams. In reality, the whole team should be working together and working closely together. Everyone does have different expertise, but at the end of the day, everyone is a user of the application and many areas will overlap, so everyone should be encouraged to focus on the whole product experience rather than just a single, own part.
So generally speaking, team members would include
1 person: the founder person leading the product vision and management.
2-3 people: ideally, the other founder person is an engineer, and with angel funding, at least one other engineer (or two) should be recruited to join.
1 person: you may not be able to hire a great full-time designer, but you should be able to communicate at least once a week
1 person: you probably won't be able to hire a full-time QA person at this point either, and in effect, the burden of making sure the app works without hiccups falls on the product department, which has only one person.
In summary, the total team size is five or six people. If the application is more complex, a larger team will be needed. Full-time designers, iOS engineers, Android engineers, a couple of back-end engineers, a couple of outsourced people to support the development and finally a QA would be brought in, making a team of around ten to twelve people.
Agile development and co-location development
Once the people are there, the specific work is generally carried out using the agile development model. By agile development, we mean delivering a valuable feature or improvement over a fixed short period of time, usually lasting one or two weeks, with the goal of starting from scratch and delivering something of value (a specific feature) for users to use. Why is it popular? Because every fortnight a new feature or improvement can be provided to users, representing every fortnight users can test the new feature and allow you to evaluate whether to keep it.
The definition of an agile team is a group of people who are completely independent and autonomous, adopting, implementing, testing, configuring a product feature and finally making it available to users. This is a pretty great concept and can work well if the team is small. The important point here is that team members should be in the same place, especially small teams with only a few members such as product/design/development. The reasons for this are as follows.
Let's start with the ideal situation. As mentioned above, the real goal of organising a (currently small) product development team is to give them the ability to quickly release new versions of the application, which relies on effective communication and is not an easy process. To be able to 'roll out new features' on a regular basis, you have to continuously improve the code, wait for feedback from users and see if the app is better as a result, and you have to strive for efficiency at every possible level. That means having the whole product/design/development/quality control team in one place, ready to go. If one or more members are working remotely, it just makes for poor communication, less opportunity for everyone to be in the same room face to face, and no way to communicate privately at all times. At the moment your team is too small to work individually yet. But if your app grows at an insane rate later on, communication will definitely remain key, so the communication culture you build now will pay off handsomely in the future.
Promotional strategy: find the competition first
Getting the app developed is only the first step in a long journey, it's more important to get users to use it. Basically the answer from inexperienced people is a thousand times the same: "We'll promote it in every way we can." That's the same as saying nothing at all. Every entrepreneur works very hard to promote their app, but only a handful of them end up with a huge number of active users in the market. So, trying very hard to promote is just basic work (or vision), but not a winning strategy.
In addition to having a vision, there's also the need for a pragmatic, step-by-step marketing strategy. The first thing you have to think about is: who are the competitors?
Take an app, and if I were to say what is the biggest competitor, I would say the gaming industry. This is no joke, simply because the first prerequisite for an app to be listed in this red sea of red is to be found, what value is there in an app that users can't even find? And when games fill up the charts of various app markets, you don't even have the chance to venture out at the most basic level. To give you another example, suppose you make an alarm clock, thinking that you might put it in the lifestyle category, but looking in detail when you put the alarm clock in the lifestyle category, you will find what houses for rent, QR codes and so on in this category, and then these are your competitors. So, in terms of exposure, the competitors are not products with similar functions, but products placed in the same category that can occupy the user's time.
I'm afraid it would be difficult for a large company to have a network effect on all users right off the bat. But if you start with a small group of a few thousand or tens of thousands of people and then gradually expand, it is something that even small teams can do, and this is one of the strategies that most successful companies use initially; it is the same with Facebook, which started on campus, and Zhihu, which started in the internet/media world. Now the question is: which small circle will get the most value from the first version of your product? And after accumulating these users, where can they be extended to?
Many people will immediately think of social media in terms of how to acquire users. Social media is the atomic bomb for the poor, but it is important to remember that playing with communities is very costly in terms of energy and money. It is called an atomic bomb because human interaction is diffuse and once you hit the right angle, the subsequent fermentation will exceed expectations. So, before you launch your product, ask yourself if you are ready for all kinds of media releases and operations.
Also, as an entrepreneur, survival is everything. When it goes live, entrepreneurs have to make corrections to the product in the fastest possible time based on market feedback, and do whatever the market likes, leaving all principles behind to meet the market.
Finally, if the entrepreneur is working on a product that needs a large number of users in a short period of time, there is no way to wait for the community to ferment slowly, but to use advertising to get a large number of users with precision. But "how to get a lot of users accurately" is also a deep skill, and behind the scenes it requires a large budget. If you don't have any school fees to pay, it's better to work in the relevant department of a big company for a few years before starting your own business, or just find a partner who can take care of this area.
Very often, we often develop many hours of products because the market does not appreciate and stagnant, while they think it is impossible to fire the small products may be in the market to brighten up, then when your product in the Internet, the red sea in the red sea was salvaged, the next step is to think about the application for the user, in the end will have how to help, if there is no real roots, and not product optimization or product pattern is big enough the market will accept. Think clearly, success or failure is in the hands of God, no shame.