Episode Description

In this episode Thanasis and Dimitri talk about how to setup project management for your startup at the early stages.

Episode Notes

Transcript

Thanasis [00.13.00]: Are you an entrepreneur? A designer? A developer? Never before has it been easier to get your new venture off the ground. Whether you’re just getting started, or have already begun your journey, you’ve come to the right place. In each episode we will dive into a new challenge, breaking it down into simple digestible terms. I’m Thanasis.

Dimitri [00.00.33]: …And I’m Dimitri.

Thanasis [00.00.34]: And you’re listening to Listen-Ship-Repeat, this is episode No.2

(Music)

Thanasis [00.00.44]: So, what’s up Dimitri?

Dimitri [00.00.45]: Nothing much, just been working on my staff. We have a quite busy startup we’re working on, trying to get a new way of doing staff out there to our customers, so we’re pretty busy on that, working late. Been also blogging too, I just wrote something on Medium, a post on Scrum and I am mentioning it just because I think it’s relevant to the podcast and what we are going to be discussing today.

Thanasis [00.01.25]: So, what are we discussing today?

Dimitri [00.01.28]: Well, what have you been up to? Then we’ll mention what we’ll be discussing.

Thanasis [00.01.32]: Yeap, I’ll tell you, because it’s relevant to the blog post on Scrum you mentioned before.

Dimitri [00.01.38]: Well, “Setting up your project management”

Thanasis [00.01.40]: Yeah, that relates a lot to the blogpost you did, isn’t that right?

Dimitri [00.01.44]: Yes, it’s about Scrum and the way I approached it was, take this blog post and it’s a great starting point and hopefully you can start implementing scrum soon. Also, you can have it a launch point for you to get deeper into the methodology. But from the feedback and from what people have been commenting, I think it’s a pretty good starting point.

Thanasis [00.02.19]: Awesome! So on my end, I’ve been mostly chilling lately. For the first time after a long time, I’ve had some dead time. Some of my contracts ended and right now I’m enjoying my free time before I get into my next project. So, life is good.

Dimitri [00.02.43]: I wish I had some free time. Anything of interest? I know you do a lot of side projects.

Thanasis [00.02.49]: Yeah! Well, we are kicking off “DEV.it”, which is an annual conference we do for wed developers. We launched our early tickets, before announcing any speakers and we’re almost sold out, which is good.

Dimitri [00.03.08]: I mean, you’ve done it twice so far, so I always wait for the latest tickets so I can support it a bit more. Like, the final bunch, the expensive ones.

Thanasis [00.03.22]: That’s great! You can buy them today, like now, if you want.

Dimitri [00.03.25]: Okay, cool!

(Laughs)

Thanasis [00.03.26]: So today we’re talking about setting up your project management and this is setting up in the early stages. So, again you have an idea, you’re starting out, you have your first developer or you are a developer yourself in which case you will have to set discipline I guess. So, we’re about to talk about how to set things up, your operations your procedures. Dimitri, why don’t you start?

Dimitri [00.03.53]: Okay, let’s look at why you should project manage. Now, we will put some special focus about you as a co-founder and your first developer. I think that you have to take project and product management seriously, at least at the point where several people are working on your product. It’s important to be able to keep your deadlines, have some sort of arbitration between team members if they disagree, dispute, resolution. A lot of developers tend to - that’s known and I do all the time - be stuck in their own microcosm. The project manager will be able to have a bird’s eye above you or the product. They’ll be able to look at the market, look at the competition and be able to move project or the product forward, coming up with new staff, new features, identifying product flows and last but not least establish discipline within the team.

Thanasis [00.05.13]: Discipline, yeah. That is why it’s very important to start building your product management procedures from day one and by day one I mean the day which you make the decision that the venture you are entering in with, will be the one your are coming out of. That means you are building out for the next ten years. So, any piece of gravel that you put into the ground is going to be the foundation on which your empire is going to be built and procedures, product and project management procedures are exactly that. They are the foundation of how your business, your company will operate. Furthermore, it dictates culture, which is why it’s really important to try to get it right from the start. Even if you’re not going to do that, there have to be some procedures in place, so everybody knows where they’re going and some kind of routine is created and everybody knows how all the team members are operating in a well defined environment. Otherwise, it’s just chaos.

Dimitri [00.06.42]: Cool! We look at the planning stage and planning means planning ahead, whether that’s something in the super short-term, mid-term or long-term. So when you’re planning one thing is very important to get right in my humble opinion and that’s product vision or vision in general. But, what does that mean? Well, you have to look at vision as the overarching goal that you want to reach, what your product wants to contribute to the world, to your customers, your long term goal and of course it’s important to communicate that to your team. Vision helps you guide your product to where you want to take it and the more transparent you are about that and communicate that to your team, the better your end result.

Thanasis [00.07.43]: And you need to have a plan, which has to be formed out of whatever method, like some lean startup, some kind of verification that your business idea is working, some validation from your first customers. So, from whatever path you come, you do need to have a plan and that plan doesn’t have to be implemented in full, but at least you have to be aware of your next two or three steps. Now, when you’re starting out, when you’re at zero, that’s where you need a plan in order to reach to your MVP, the Minimum Viable Product. You need to have a crystal clear idea of where you’re going when you’re starting your journey, otherwise you’ll drift away. This is so important that you need to write it down on a piece of paper and stick it down next to your office, so you know where you’re starting and where you’re going. At any point you may change course, but that paper needs to be there and it needs to reflect the latest and most updated path that you choose to take. So, in essence you need to establish a road map and at the same time you need to be able to throw away that road map, but knowing where you need to lead your team next produces so much better collaboration between the team members, even if it’s just one person, because it gives them the ability to think about problem solutions in a bigger picture, which is the one you give them. That compared to not knowing where we go and deciding on a daily or a weekly basis what will be the next feature, you know when we see something on a website and we say “Oh that’s nice, let’s do it”, another thing on another website “Oh, that’s very cool, let’s do that as well”. That’s the point where you start to drift away, lose course and not being focused on what you do. Previously we talked about throwing away your road map. There are those cases that you are not a hundred percent sure about what you do and of course you can never be, but I’m talking about these times where you have a lot of uncertainty, you’re not sure if the path you’ve taken is the right one, you still haven’t received any results, neither negative nor positive. When you find yourself in this situation the best advice I can give you is to stay true to the course, stay on your original plan, on your gut, your intuition on whatever you have validated through your market research or from talking to interested customers and the answer will eventually come to you. So, what I’m trying to say here is change the course only when you’re sure where you’re going.

Dimitri [00.11.09]: In addition to staying in the course, building a road map, presumably tasks that make up the road map, your long term of the mid term. There are a couple of other things that you have to take into account while planning. First and foremost is, identifying risks and in the context of planning, identifying risks is something you will be spending a lot of time on. But, is it worth it or will it pay off or is it something proved to be unnecessary and time was wasted while building it? Also, looking at single points of failure and bottlenecks is rather important, as well as roadblocks or blocking issues tasks in this case. Specific case for that would be - and that arises quite often as a matter of fact maybe on daily basis or maybe not, but you definitely see it - blocking issues between team members. There might be a lot of dependences, people waiting for a task of one member to finish before they begin with their own task. So, please take that into account while you’re making your plans. You might have other projects while you’re waiting, maybe you’re waiting for a data or an API N point, maybe you can learn to test data fixtures, that was a very specific example that I gave, but you get the picture. Also, something that I’ll just breeze through, troublemakers in a project planning. Rule of thumb, if things start to become toxic, it’s decision time on who to keep onboard, so keep that in mind.

Thanasis [00.13.12]: So, you know, the whole thing here is to have a plan and since you mentioned bottlenecks, they can only be visible if you plan ahead. In order to give it a more material substance as to what a bottleneck might be, a bottleneck can be like, a design your waiting and the designer is a contractor so you cannot really be sure about their delivery time or when special infrastructure is required, because you do extensive processing in the background and those kind of things always trick up delays in the planning, but for you to be able to see those bottlenecks and pitfalls you really need to have a plan and you need to stay focused on that plan, on that road map. Yet, at the same time you need to be flexible, I mean, even the name of our podcast is a startup mantra itself, it’s “listen” to your customers, “ship” your codes, “ship” your deliverables and repeat, “Listen - Ship- Repeat”, that’s what we are about. So, let’s try to go through all the available methodologies today. The first and foremost is to apply common sense, now of course common sense might be different between people, but try to establish some procedure on whatever that is, okay? So, it’s day one at your office, you and the developer so you need to establish some form of communication and that is some type of formal communication, in the form of a procedure and that is very important so both sides, both you as the founder and the developer know what to expect from each other. You could have weekly plannings, monthly plannings so then you will be able to see what actually happened, like “did we finish earlier?”, I don’t think so, “did we finish later?”, which is mostly the case. After that you can start observing and better calibrating and tuning your project management operation in order to be even better as time passes at predicting how or when the codebase, or generally the deliverables will actually be delivered. So, what’s next Dimitri?

Dimitri [00.16.02]: So, it will be worthwhile mentioning at this stage a couple of formal processes, because at some point if you are fortunate enough to grow your team size, get a lot of people, you will have to look at a formal way of delivering and shipping your product. So, I’ll just go through some methodologies that I have cherry picked, they are by no means limited to that. The first is agile, you’ve probably heard that, agile isn’t a specific process of building software or products but rather a set of principle that you can apply and there are a lot of substitutes of agile. The most well known or the one that we can characterise as the most popular today is scrum, a little about scrum in a second. The important thing about agile, is that the keyword is iterate, iterate, iterate. We will be able to look at scrum later on. Scrum is a formal way of building a software, it has specific roles assigned to people and specific meetings between team members on specific dates and specific delivery times at the end of a given time period which is called a sprint. In order to be focused on the way you’ll be building your product by using any of these, there are some great tools out there, “Jira” by Atlassian is well known, “Trello” is also well known and that can be used in the “Kanban” way of building staff and if you take a look at trello, which have, or at similar staff, it’s a board and the board has columns and each column has tiny stickers and each sticker or card is the task at hand. In Scrum it’s a bit more involved, for example you have your product backlog, which is the staff that you want to build in the future, items that are in your current sprint, like staff that you want to build now, at the end of the current time period, “in progress” and “done”. Kanban is a bit less involved than that, you basically have “in progress” and “done” items and perhaps some sort of idea from where you want to pick items to work on. Other software packages that you can use is “Geekbot” which is a great twic that you can use on slack and that will help you with your daily standups, if you chose to do scrum. I mentioned Trello, but also worth mentioning is the Github’s tool which is quite similar to Trello, so if you’re using Github for your issues and your source, there’s another incentive for you to use their own package. Honorable mention, “Waterfall”, IOs like to say that if you don’t know what methodology you’re using, you’re probably using Waterfall. Your projects or items or tasks are in sequence and when one of them finishes, the next one begins or towards the end. So your requirements, then your design then your implementation, then your testing or your maintenance. One last thing, you mentioned common sense a bit earlier, so a nice tool to get you started with would be “Basecamp”, a lot of people call it a to do list, but it’s an excellent to do list, great tool to get you started.

Thanasis [00.20.37]: Yeah, absolutely! Be rest assured that we are going to dedicate a full episode on methodologies, what we work on and what we’ve seen in the industry. One thing to take note here about the whole management procedures, is that with every procedure that you put into place you create an administrative overhead and the smaller you are, the less overhead you have to have. That is extremely important, in order to retain your flexibility and our velocity, because in simple terms, the more paperwork you have to do, the less time you have to do your job, you know, the actual programming. So, to that end, fully adopting methodologies and all the procedures and having strict procedures in place is something for a later stage company, because methodologies pay dividends as the team scales. At very low number, like three or less people it’s good to have a basic structure in place, but at the same time you need to retain your flexibility and velocity, so feel free to break any rules you consider necessary as long as they make common sense.

Dimitri [00.22.19]: Now, it’s all been great so far, but what’s the glue that holds, not only products together, but everything together. Communication, and the accompanying feedback loop of the communication. So, you start working, maybe you start with a common sense approach and that’s great and you have all these team members now. The only way to make this work perfectly or great or adequately is by communicating. One of my favorites - and I do this a lot, I do this on my full time project, I do this a couple of pattern projects once I’m involved with - is the daily meeting, the daily standup, timeboxed, tiny meeting, making sure that everyone involved is present and it’s the way you discuss your progress. Now, I’ll be careful not to call it a status update, I’ll be calling it a progress report in order to facilitate transparency in my team making sure that everyone is on the same page and making sure that everyone which depends on me, in the case of a blocking issue or something that might become a blocking issue, we will be able to communicate when I think I’ll be able to deliver. So, you can mention what you did yesterday, what you’ll be doing today, what you’ll be doing in the short term and identifying blocking issues and at that point you can mix and match and say “Okay, that’s what I’ll be working on today, because there’s a blocking issue” or you can say “Great, there was a blocking issue yesterday so I can start working on it now”. So, a summary of what I was doing yesterday, what I’ll be doing today and what kind of blocking issues were on my way and who can help me. That will help you identify issues and apply changes early, you repeat that process everyday and hopefully you might get a smooth project management experience. By the way, blocking issues aren’t the end of the world, they will happen, but the important thing is to be able to identify them early enough so they don’t continue existing overtime, get them out of the way as soon as possible. If you work in the same area, or the same office you can all gather around and have your standup around your watercooler or the coffee machine, you can do it with “Slack”, the popular chatting line, that’s available now or even via skype as a conference call. When you have these meetings don’t be afraid to talk about irrelevant staff, it’s nice to catch up with the team, not only on just the work level.

Thanasis [00.25.22]: Right! Since you are a startup and you’re trying to find your product market feed, in terms of communication in feedback loop, there’s nothing more important than staying in touch with your customers, listening to your customers. You have to make that a process and you need to engage your whole team into that process. So, depending on your particular scenario, if you are a consumer application for instance, the process of listening to your customers is going really deep on metrics and winding everyone up towards that extent, so for whatever action you do, there should be a metric that measures its effectiveness, like “do the users like it?, “do the users don’t like is?”, “has it changed anything at all?”. In the case of B2B businesses, SaaS applications, then pick up the phone, start emailing, talk to your customers directly and out of those conversations you are going to understand what they need, what direction you should take and the way you involve your team into that, especially in the early stages where everything hasn’t still taken shape is actually putting them in front of customers, making your developers do support, making your marketing guy do sales, it’s not that much at the beginning. In that way make sure that everybody gets some battle time with your customers, right? Of course it’s not actually battle, it’s speak time, but in the mind of a developer, talking to a customer is the worst thing that you can do to them. So, it’s that kind of battle.

Dimitri [00.27.25]: It is and you will be doing support in the beginning or beyond. I think it applies to every role, until you get people filling up those roles, I think that everybody has to wear a different hat in a startup.

Thanasis [00.27.40]: Right, but I’m saying you should do that on purpose rather than by accident.

Dimitri [00.27.44]: Yes and you have to love every second of it. You mentioned before about the team, I’d like to mention team spirit and that kind of goes along with the company culture too. You mentioned keeping people involved, in addition to that always try to treat your team well, always thank them, actively pursue suggestions from your team if you are in the project management role. You have the bird’s eye view of the product and you have the customer input, so you also have to value the input from the people that are actually working on this. Not everything has to be accepted, some of the staff will be rejected. I find it nicer to reject staff a bit later and not straight off the bet. Always solicit initiative from your team members, always encourage them to come up with their own ideas, especially tech ideas because as we’ve mentioned previously, you can course correct when listening to those great ideas which might come in.

Thanasis [00.29.08]: So, you need to actually solicit initiative and to that extent you need to not isolate team members. It’s often the case were at the very early stages with three or four people, the founder neglects to give speak time to the developers because a developer is naturally an introvert and won’t come out of themselves. It’s your job as a founder to come out and talk to them, open them up, listen to their ideas, because at the end of the days, let’s face it, the developers had been working at another company, they did have some kind of procedure there which they are trained on. So, more likely they are going to have more ideas than you as to how things should be run and operated and you need to have an ear for that. Now let me make my closing remarks, which are as I said before, don’t fall into the micromanagement trap, you can very easily get caught into the process at the very early stages where you don’t know exactly what to do, you decide to do all of them and that adds up so much administrative cost and overhead to your company that you are not going to be productive, efficient and you won’t be able to deliver in time. Staying focused is one of the most important things that you always need to keep in mind. I’ve found myself so many times having conversations where we went totally adrift all the while and the founder believed that it was the main focus, when that wasn’t actually the case as proven by the market and the feedback we got from the customers. So, don’t go towards that very attractive light that you see on Facebook, on Instagram, the latest thing that they did on Twitter, because you really cannot compare with those companies. You really need to make very little iterative steps, thousands of them in order to get out on the other end.

Dimitri [00.31.43]: Nice! So, I think we’ve covered the importance of project management. You need to project manage even at the smallest size possible, but you definitely have to adopt some form of procedure as you grow. Your goals will always be, you know, to ship great staff to your customers which they will love. Make sure that your team does everything in order to achieve that, while they have fun and communicate at the same time and it’s your responsibility to be able to plan ahead and communicate you planning and your product vision to your team as often as possible. That way, you’ll be able to ship great products which your customers will love and you will be having fun during the operation and during the process.

Thanasis [00.32.40]: Awesome! So, that’s all from us today. So send us your questions by calling us on +1 866-3705-050 from anywhere. Email us at hello@listenshiprepeat.com. Subscribe on iTunes by searching for our podcast or visit our website www.listenshiprepeat.com. Thank you for listening! See you next time!