Entrepreneurs in Finland-Suppourt community
Login / Register

Community talks

  • 5 Skills Each Entrepreneur Should Learn from Project Managers

    This article was originally published at https://nordicfounders.com/5-skills-each-entrepreneur-should-learn-from-project-managers-b72e0362bfab#.2r0vdh268

    I took a job of leading engineering and product development in an internet startup, after being a PMI certified project manager in Nokia for 4 years. It has been great to switch from a usually slow corporate environment to a fast-paced “get the things done” mode. However, after getting to know many early stage startups, I have noticed that very frequently even basic project management technics are not used. This is where I realized, that a formal corporate project management experience is a great asset for any entrepreneur. Here are 5 PM technics I have been heavily relying upon for the past 3 years as head of product @Eliademy.

    1. Treat your product as a set of projects with clear goals

    Product development never ends in a startup. It simply should not because every day brings a new idea, requirement, or a suggestion from a user. The ability of frequently iterate and improve the product is an essence of any successful startup.

    On the other hand, as a project manager, each project should have a very concrete goal and an end. This makes leading engineering and product development in a startup is equivalent to a program management in a corporate environment. By definition, a program is a continuous activity which consists of finite projects.

    Ability to chunk startup product development efforts into concrete and measurable projects (which lead to a better overall result) is the first useful skill each entrepreneur needs to have. Divide and conquer.

    2. Define what you will not do

    Lean startup MVP concept teaches entrepreneurs to describe finite set features that need to be implemented in a product. This principle goes especially very well if your startup follows Agile principle and center the work around user stories based on concrete requirements.

    However, project managers usually take this concept much further with a project charter — a document which describes not only the features that need to be implemented (in scope) but also everything which should not be implemented or considered (out of scope).

    An example — “User should be able to login with a social profile” story needs to be translated in more formal:

    • In scope — conversion to a regular account if a user lost access to social network
    • Out of scope — an automatic merging of accounts if user signed up with multiple social accounts.

    Clearly stating all limitations is a practice that leads to a higher success rate and allows seeing all dependencies even before project/product development starts.

    3. Estimate better

    Getting and accurate development estimates is a science on its own. However, very frequently problems occur not because of incorrect estimates, but because of dependencies on various people on each other (or 3rd parties if you decided to outsource part of your product development)

    PMI project managers usually employ PERT method to make sure the project gets done on time. It employs 2 main concepts.

    First, ask development team to provide 3 estimates instead of 1 — an optimistic, pessimistic and most likely (honestly it takes almost the same amount of time as asking for a one). The “expected” time then calculated like this:

    t = (optimistic time + 4 * most likely +pessimistic time) ÷ 6
    Typical PERT chart https://en.wikipedia.org/wiki/Stakeholder_management

    Second, build a “scheduling” diagram that takes into account all dependencies your team has and expected a time of each task. For example, it is not possible to start developing of the frontend, until UX design in done. At the same time, UX designer can’t start work until most of the requirements are fixed. Thus, developers can focus on backend until design spec is ready.

    Visualising each task duration and dependency against a simple week scale (it is usually an x-axis) gives a very accurate outlook on the project duration.

    4. Fight deadlines

    Being late with a product is a typical situation in a startup, which most frequently result in everybody working day and night just to meet the deadline.

    Formal project management always sees such situation as a failure in planning (see bullets 2 and 3) and sees only 2 solutions:

    • Crunch the scope
    • Crunch the schedule

    Crunching scope means removing certain non-critical items from the product. Trust me, most MVPs always have something non-critical and such stress testing is the best way of really seeing what your MVP is)

    Crunching the schedule is add people to the project in order to help. However, it is considered to be largely ineffective during the later parts of the project and should be done as early in the project as possible.

    Hacking up all weekend is certainly fun, but remember it leads to substantially decreases ability to focus, creativity and productivity in a long-term, which you definitely will need in any startup.

    5. Manage stakeholders wisely

    As an entrepreneur, you most likely will end up talking with many people every single day — your users, clients, employees, investors etc. It is very frequently overwhelming and even more frequently you don’t see the help all of those connections can offer to your project.

    On the other hand, as a project manager, I learned to classify each person has an interest in a project into 4 broad categories (with matching to startup roles):

    • High power, interested people (in a startup this is your paying customers)
    • High power, less interested people (those could be your investors and board)
    • Low power, interested people: (advisory board and employees)
    • Low power, less interested people: (reporters, to some, extend your free customers)
    Stakeholder engagement matrix https://en.wikipedia.org/wiki/Stakeholder_management

    Understanding your stakeholders, placing them in a right quadrant of engagement matrix and choosing the right form and frequency of communications not only will keep everyone involved up to date with the progress (instead of being annoyed by a barrage of emails from you), but will also free up lots of time which can be spent on making your product better.


    Written by Sergey Gerasimenko

    Sergey is an engineer and project manager turned social entrepreneur. He is a founder and head of product at Eliademy. On his free time, he runs Nordic Founders - a support group for first-time entrepreneurs in Helsinki and helps growing project management community as a director at PMI Finland Chapter.   





    Read more »