Companies that deal in software development can be divided into two rough categories: by-order developers, who make one product and sell it once to their client, and product developers, who make one product and sell it many times, with no particular client in mind. The latter kind of companies employs product managers, who serve as a sort of in-house client. Their task is to determine what kind of product is in demand and explain the task to the programmers.
Most of the time, a project manager’s responsibilities are the product manager’s, too. First, you come up with a product, and then you put on your project manager hat and see the mission to its end.
A few people seem to believe that a product manager is some sort of wizard who comes up with the right ideas on the fly and knows how the final product is going to look, work and what it’ll take to make it. That, of course, is not true. One of the most common reasons why startups fail is that there is simply no demand for their product. Too often someone has a brilliant idea and everyone else spends time and money on it, only to realize in the end that no one is particularly interested. The same happens in major companies, too.
Lean Startup
In the Silicon Valley, where that problem was also commonplace, a movement emerged called Lean Startup. It is based on the idea that nobody can say for sure how to make something truly great, but people can make a damn good hypothesis. A product manager’s task, therefore, is to find the simplest way to test those hypotheses. This method was adopted by major companies, as well, and now pretty much everyone is using it.
What is the development cycle like? First, you have an idea. Then you pick the simplest way to implement it and show it to others. When you have a simple product, you put it on the market and observe, collecting quantitative and qualitative data. Then you use this to figure out how this idea may be improved. And back to step one. The faster, the better. In best cases, it’s only a week between the idea appearing and it being tested. Months are less preferable, and years are definitely out of the question.
The ways of checking a hypothesis differ depending on the project. For instance, Yandex.Realty lets its users list apartments for rent or look for an apartment to buy/rent. At one point we thought: why not make a mortgage calculator? How do we see if that’s a good idea? We put a button on the site with the large words “calculate your mortgage”. Doesn’t matter where it leads, to Wikipedia or a banking website. If users click on it often enough, we make it. If they don’t, then it’s not worth it.
Here’s another example: let’s say you want to make your website faster because you think it’ll make people use it more often. But such things cost money. In this case, you can try the opposite: make your site slower and see how that affects its popularity. If nothing has changed, then the same will likely happen if you improve it.
What does this mean for project management? First off, we don’t have a long-term plan. What we’ll be doing in two months’ time depends on today’s experiment. Secondly, we can’t give a precise evaluation of a product, as we simply don’t know how it’s going to go. Thirdly, the product manager has little time left to manage projects because they also have to create hypotheses, test them and work with the market.
So how do you handle it? First, you need to learn to adapt quickly. Writing an in-depth technical description and working on it for six months straight isn’t for us. Secondly, the team has to take part of the responsibility for managing the project, giving the product manager more time to do other work.
Agile
Agile is a project management philosophy. A few decades ago people took notice of the fact that most projects (about 70% of them) don’t end well. They miss their deadlines, overspend their budget, or just end up delivering a bad product. However, some managers’ projects turned out better.
So these people got together in 2001, in ski resort in Utah, and developed a methodology. Their individual management styles differed in details, but they all had some principles in common, which they dubbed Agile.
These principles were expressed in their manifesto: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan.
What does it mean for me as a product manager? It means less planning and more ways to adapt. Agile improves teamwork, too. It makes people think how to reach the common goal. One issue is that Agile doesn’t provide any specifics; that’s why we have frameworks that describe how to manage projects while adhering to the Agile manifesto. There are a few, but I’ll mention the most popular one, Scrum.
Scrum
The word Scrum comes from American football. In that game, every player has their own role, but if someone from the opposite team grabs the ball and breaks through your defenses, the whole team has one goal: to not let that player score. It’s chaotic and messy.
That’s what Scrum is in software development. The team has a common goal. And while every member has their own role, be it developer, tester, or designer, when the common goal is under threat, it no longer matters who you are.
A Scrum team is usually made up of five to nine people. The teams must be fully capable of delivering a final product to the customer. You can’t have a team of just designers or backend devs. The teams have a product owner, who explains the current tasks to the development team, and a Scrum master, who ensures the effective use of Scrum within their team and takes care of the staff’s happiness and professional development.
The development process
Any large project is split into several smaller ones, each called a sprint. That’s a short period of one to four weeks. At the end of a sprint, you need to have a working product that’s ready to be used by end customers. We can’t spend two sprints on design and only then start the development process. That goes against the spirit of Scrum: after every sprint, users get something of value, some useful feature.
It starts with a planning session, during which the team decides on the sprint’s length and tasks. There’s no point in debating the order of tasks; this is done on a daily basis during the daily scrum.
Another useful tool is a scrum-board, an actual board with the columns “to do”, “in progress”, and “done”. We put all of the current sprint’s tasks on there and do the daily scrum in front of the board. It should be noted that in Agile and Scrum, the best communication is face-to-face. For that reason, it’s better to have one room for everyone on the team to ensure a constant exchange of information.
When the sprint ends, the team gets together for two meetings. First, a sprint review, where we show our accomplishments to others, get feedback and use it to draw up the next plan. The retrospective is the final Scrum meeting. At the review, we discuss what we did; at the retrospective, we discuss how we did it. Every team member gets to say what went well and what could have been done better. Those suggestions are noted and used to formulate the tasks for the next sprint. This way, there is a constant improvement to the working process.
Needs and requirements
Agile is focused on end users and their needs. That’s why the concept of user stories has become popular in the context of Agile. A user story describes the requirements for a final product in the language of an end user. Our user stories follow a pattern such as: I’m user so-and-so; I want to be able to do this-and-that in order to accomplish such-and-such.
For instance, as a realtor (1), I want to list an apartment for rent (2) in order to find a customer (3). Why are all three parts important? Because who we make it for determines the final product. Interfaces made for realtors and for homeowners will be completely different. And the users’ end goal must be clarified and memorized in order not to lose track of it throughout development.
Scrum and long-term planning
Scrum is often criticized for being “too tactical”: you only see as far as the current sprint. What about strategy, a general objective? Companies that adopt Scrum often have two separate plans: one is long-term and one is a Scrum plan that the team works with. Thankfully, Scrum can easily be combined with other methodologies.
Long-term planning is always a source of problems; people are very bad at estimating how much time they’ll need to accomplish something. But, at the same time, they are pretty good at comparing the amount of effort needed for different tasks. This is the basis for the story point technique. Story points are sort of a measurement unit for user story evaluations. We grab the entire backlog and ask the team to choose the smallest, quickest task. That task is our story point. All other tasks will be evaluated in comparison to that one easy task, and measured in story points instead of hours.
Then, we do a few sprints and see how many story points, on average, our team can do in one sprint. Now we know the size of every task in story points and the team’s production speed in story points, and that lets us evaluate development times far beyond the limits of a single sprint.
What to learn today
When you’re looking for work, it’s highly important what sort of company you’re choosing. There is no perfect company; everyone has different tastes. When you come in for an interview, look at their values, their culture. Some important questions to ask them are: who will I get my tasks from? Can I change my task if I don’t like it? Do you use Agile?
If you’re interested in a career in management, keep product management in mind. I think it’s a very interesting job, as you get to see how a product is made and also affect others’ lives.
Higher education is the perfect time to launch a startup, without five kids and a mortgage to think about. While you’re still a student, you can afford to spend two years or so eating instant ramen and trying to change the world. But I implore you: don’t polish one brilliant idea for two years before seeing if it works. Test every hypothesis you have. If you don’t know where to start, find a mentor.
