 I'm walking around with Mike Sumberland, so you might have to shuffle in a bit if you get more people. Cool, so I'm Jeremy Alexander, I'm currently the Web Development Instructor at General Assembly, and I'm currently teaching my fourth factory student, some of whom are in the audience today, and in total I've taught about 80 students. And I just wanted to share with you some of the experiences I've had watching them build products. So to go back in time a bit, about 10 years ago I set up my own development shop, and my first project was a game working with a bank to help kids learn how to manage their money better. I had like a really crazy revelation the other day, and I remember doing some user research for this project, and being in a school, doing focus groups, and the students were about 15, now I realise actually, they'll be like 25 years old now, hopefully they're like managing their finance as well because of what we taught them in the game. But then, so moving on from that, my last product was a platform for connecting grandparents and their grandchildren through the customisation of interactive stories. Now between that point, between those sort of 10 years, I've done like various projects in gaming, in VR, in web, mobile, and even in interactive teddy bears, so all sorts of experience. But when I moved to Singapore, I think I was ready for a new challenge, so I created something new, and I threw myself out of my comfort zone, and I took up teaching, which is like the worst thing for a software developer who's used to just hiding in the corner. So I joined Gem on Assembly, and in the past year, I've taught the Web Development Immersive, which is a 12-week bootcamp, where you take people from non-coders through to getting their first jobs as junior developers of some of the best companies in Singapore. So I personally taught over 80 students, and on the course they make four projects, so each one a one-week spring. So in total, I've probably seen like, well over 200 projects go through, but I thought like, 100 down to catch you, so it's 100 Mbps as opposed to 200 Mbps. And so what I wanted to talk about today is like, not what I teach them, or how do I get them job-ready, but what have I learned in the process? So inadvertently, what have they taught me about product development? So the first part is like, where do their ideas come from? And I think this is the part I really love, right? I like seeing like, we don't tell them what to make. We give them a week and then say, alright, so you're going to have to build something, and then they have to come up with something to build, and then they have to build. So trying to see the sources of this inspiration is really exciting. And I've categorized it into, I suppose, three main sources, just because everything's better as a tri-question, right? So I think the first one is they scratch an itch that they or their friends have. So whether that's a case of that they might want to build a sporting platform for like, organizing group sports events, or they love aeroplanes and they want to be able to track them all the time whilst they're in the sky, or like, occasionally they inadvertently end up scratching my itches by like, building platforms to find the best coffee shops or co-working spaces in Singapore. And so I think this is something which is really common. And I think another way is, like, when people come to the course, they often have a prior career or previous experience. And one of the avenues I see is that they try and form a synergy with what they previously knew and what they're learning here. So like, for example, that might be a finance professional looking at how they can do predictive modelling on like, their returns on investments, or it might be somewhere from an architecture background trying to make a crowd planning platform for, you know, housing. How housing is going to work in 2050 when you can reconfigure apartment blocks. And I think that these ideas are also really exciting because they kind of, they're at that intersection between, between what? And then sometimes they like, I suppose when they don't have an existing itch or they don't have some prior experience that they want to utilise, they end up making a sort of an M2 product. Like something which works really well in another market but perhaps just doesn't exist here yet. So maybe that's like a co-buying product or maybe that's a task running platform. And so I think that that's often another source of their ideas. And so I think, like, whilst it's interesting to see where the ideas come from, it's then the next step is like, what do they actually build? And we don't tell them what to make but we do give them technical requirements. So we do say this particular project has to be built in Ruby on Rails, it has to be the Postgres database and a user must be able to sign up, a user must be able to log in and then you have to use at least three database tables. So we give them some technical requirements but then they are still very free and very open to decide what features to implement. And I think, you know, often it is a technology push. So often it's a case of there is some really interesting framework or API that they want to use and then they can see features that take advantage of that. Like Google Maps is incredibly popular. I think that a lot of students try and have a Google Maps-based project there. But also like public APIs like data.gov.sg or Spotify, like all of these open sources, people see these really cool technologies and then want to play around with them and think about features that enable them to do that. Now, unlike, we also have a user experience design source. Unlike our user experience design source, we don't require students to go and do customer research. So I think the majority of our ideas are not what we say like market call ideas. Now, I think what's interesting about this is like once in a blue moon, we do get some students who will go and do like customer validation and maybe they even extend out these surveys. And this is really cool. I say once in a blue moon, this has happened once. All of the students I've thought, this is the only time I've actually seen these surveys presented in a presentation. So once in a very, very, very blue moon. And then there's something else around quality. And this is like a bit of a confession and it's something which maybe isn't obvious. But often the products with the richest features, the ones that look the most polished are not necessarily the ones that are the most technically robust. Or the ones which follow the best development workflows. So like on the course, we teach a lot of our job development best practice. So things like test driven development, pair programming, continuous integration, lots of this really cool stuff. And occasionally, slightly more often than the blue moon, but occasionally we see students implement these to a T and they end up with very nice, very robust products. But they're often just not that sexy. And I think that this is something which kind of makes me reflect on my own parts. This is something I've seen in my own experience and in startups is that often we just assume that robust, reliable, high quality products are the side effects of great developers. And we don't allocate them time in that product roadmap. And I think that this is perhaps a mistake that we often make is we should be thinking about these like four features of our product if they're important. So how it actually gets built, this is the fun part for me. And I spend far too much time trying to categorize everyone into these molds. And obviously, because everything I like is in threes I come up with like three categories of makers. So how do they go about actually building this stuff? The first time I like to call the artists. And for them, like, the work is never finished. They never have an intention of having a complete project after this week-long sprint. They just have this grand vision of something that they want to build. And it might be something that they've always wanted to build, or it might be in something that they think is going to be this next big unicorn idea. And they just do as much of it as they possibly can within the time frame. Interestingly, I say that I would probably cast myself as this first type in that I have these really grand ideas and I just try and do as much of them as time permits. The second type I like to call the tailors. And I think we're going to may have an impeccable sense of time management and resource. Perhaps they're coming from sort of project planning backgrounds or other roles that require them to be very analytical. And they're really good at working out exactly what's achievable within the time frame. So they have one week and they manage to design and conceive a product that they can implement perfectly in that timeline. So whilst their ideas might not be the most ambitious, they often do end up with very polished looking products, very polished finished product. And the final group I like to call the sculptors. And I think the difference, once my slides, I'm going to be low. The difference to this final group is they break everything down into really tiny chunks. So they always think about it as what's the smallest thing I need to do. And then they start with that. So they pick one part and then they finish that. And only once that's finished, only once that one component is perfected, do they think about what comes next. And so whilst I think they might not end up with the most ambitious project starting with really ambitious ideas, and whilst they might not end up with the most polished projects, they're always the first students to meet the technical requirements of the assignments. They're always the first students to take their thoughts of having passed. And I think often they end up exploring one or two features to a really great level of depth. So something which on the surface, like a rating system which might seem very simple, actually has like a lot of research that's gone into it. So, what about the results? So we kind of talked about where these ideas come from, what features, what they decide to build, and then their personality types that, you know, how do they go about making it. So, I apologize for my slide, there are too many animated gifts and videos in there. Like of internet. Let's go, go. But let's talk about the results. So, I want to start with the obvious. I'm trying to anticipate some of your questions. So, one part would be like, well, is this just, you know, is this just type? And I think some of you may be thinking, well, how much can they actually know in 12 weeks? Really? Can they, you know, am I just like overselling it? And am I just trying to get more people to sign up for GA? And I think like this is you really have to just dig in and see these products to really understand actually a lot of this is technically and idealistically very exceptional. So, like, for instance I even had like one student who designed and built a product that I had had the same idea and like I had literally been wireframing a couple of weeks ago. And, you know, the difference was that she built it in one week whereas though I had like bookmarked times, like three weeks in the future to actually even start on it. So, you know, she had the first mover advantage and yeah, I know it's annoying, right? But also, I think that this kind of goes into something else about like this whole notion of this or rock star engineer and I'm not claiming to be one, but I think, you know, I envy the students a lot because they have maybe sort of 28 plus days over the course to work on projects and those are usually at least 12 hours a day. So, we're talking 300 plus hours to work on stuff and me as as a developer still developing, maybe I dedicate like an hour every evening, every one evening to do my projects. Like, for me to put in that same amount of time it's going to take me over a year. So, I have to be like at least four times as good just to even keep up and I think that that's something which is really interesting and worrying for me as one of the rock star developers. But I think, you know, part of that it's kind of okay, I think we're not out of jobs here and I think the big problem is that whilst I always try and impose these students to like publish their work up a bit sign up real users send that press release out to Technasia get that product out there like it seldom happens and I think unfortunately I know of maybe one product out of all of them that's still in active use and I think that that's quite sad I think that's the sad part and I think to some degree it's because people they get jobs and then so they have the same time problems that we do, so the same constraints but I think also unfortunately I think it's about belief as well and I think much like some of you might think, well how much can they actually know in 12 weeks I think the reality is that often that's something that they feel themselves is after 12 weeks how good can I actually be am I good enough and so trying to install confidence within the students and trying to get them to believe in themselves is one of my hardest jobs as an instructor and I think consequently it's something that I understand quite well in a personal level and probably one of the biggest things I've learned about building products is as often quite introverted makers we love what we make and any time that we release a product we are putting it out there to the wild and we're we're seeking like validation on a personal level as well as in terms of the business idea and so whilst an MVP might be like the greatest route to success you know give us the quickest way of learning it kind of goes against that natural instinct that we have to sort of protect ourselves from like a broken heart and that's maybe a bit too deep so here's a game that one of the students made looks cool thank you questions, Q&A, discussion ideas, disagreements Hey, so WDI1 and stuff like that I like what you said about the fact that you're focused too much on the tooling and the project right whatever that means but I have to say that you've actually made a good career out of that so that's a really, really good role and I enjoyed it very much I think it's that that idea that they I think they are kind of the things that you need to be thought about it's that kind of like thinking about the tool and thinking about the strategy to building the best product building the product and I think often I suppose like blindly we can just assume that they're the same you have great developers they don't need to think about the process I don't know if there's a name for the role there should be, shouldn't there we should come up with that I don't know if I could just riff on that having done a start I'm just going to I think it's the pressure is very much on the future can we erase the future at least in the early days and writing the code myself I'll come back to this later and because 50% of 0 to 50 is better than 0 and then getting the 80 maybe sometime in the future which you may not be around for at least in the start a lot of times the code I think what's important is you accumulate the tech but you know that you're doing it as a conscious decision to make that trade off I think that's something that takes time to kind of figure out is this the right thing or not being able to just quickly say oh shit this is wrong let's fix it now before it gets even worse I totally agree and I think it is about that relationship with your customers as well so it's like you say you take on some of that technical debt knowing that you might address it in the future but what's the message that you send to your customers is the liability of your platform is it about trust like the first few percent today is that the most important reason why people come to you and if so do you need to like prioritize a lot of this a lot of that stuff over the sort of breadth of future sure yeah I mean I guess I guess that part is kind of it has to work externally it has to work right the question is do you use this concept of yapping you're never going to need it right so you could build some really I think I'm struggling to come to the right analogy but like say a bicycle kind of works for now right and you can think that your vision might be turning into a flying airplane but maybe that's not where the customers end up or what you need or want or whatever so you kind of just consciously say I know it might turn into a plane one day but I'll tackle that problem when it becomes a problem you see why that doesn't work they have no choice to not come to you they must stay a million hours no I think that's fair I mean I would say if I were honest I would say that the biggest factor is passion I find that occasionally it's for some people like getting into coding or they're interested in coding and then they get into it and their hearts are just not enough and I think that that's by far the largest reason so even if someone it doesn't maybe have the very strong mathematical or logical foundations but they really love an idea they find a way so they find a way to get to that and then likewise for those who are technically very strong they get to a point but it's the one where it gets to 459 and they're like I've had enough coding for today and I'm going home I give up so it sounds weird but I think it is all just about how much they enjoy what they're doing and how much they need to invest during that time if you were to stop teaching and then move on to another job what do you think what do you think would be the biggest takeaway you will have from having done this the biggest takeaway oh that's a tough one I think if I go back to my sort of categorization of types of people and sources of ideas I don't want to say I don't believe in my ideas as much but I think I'll be less dismissive of other people's ideas which sounds silly and it sounds so obvious and it is obvious but I think often we just believe our idea is better than everyone else's idea and our approach is better than everyone else's approach and I think maybe I'm a bit less opinionated a bit more open minded now would be one take away is that the best one maybe maybe just being a bit more a bit more open minded I understand GA does do job placement for their students real jobs so how do you actually combine the startups many of them love money and effort building up something for their business to actually place their trust with someone who has only done it for projects that's a great question I wonder whether I'm going to graduate with jobs in the audience I wonder whether any of them will want to answer that question for me also I'm happy to I think ultimately I remember once a friend of mine was telling me that we thought that after two years as a developer there was no difference in our experience and I think his argument was someone who's really proactive in their learning and their growth after two years working in a particular field made a lot of depth there and ultimately it's very easy for someone to sit in a role in just like coast for ten years so ten years experience is not necessarily better than two years experience and I think interestingly as well like now even if you look at tech technology is so critical so the stuff which I learnt when I was studying is not the stuff that I'm applying now and so probably the most important skill for a developer is their ability to learn and to pick up new frameworks to have a good foundation but to be able to pick up new stuff and so that's a lot more about attitude, approach and attitude than it is about the particular tech staff that they know and so I think whilst you might get someone who's been two years working with a particular tech staff, if they've got the wrong attitude, they've got the wrong attitude they're not going to be able to progress from it so I think what the start-ups and big dev shops who recruit from GA value is the raw materials it's like coming and finding people who are really passionate, really hungry and they know that if they invest a year two years in this person this person will be on the road to being a rockstar engineer so you talk about some engineers being the artists on the road being a product manager I've managed a lot of projects which are done by the so called artists things that are specific to them and so that's kind of like because the confusing part of I think the moral the moral dilemma as a product manager we face is that sometimes we do get that feeling that they want to have this brand vision they want to have this great product but of course the pragmatic mindset is that they just need to get some vision really it's that feeling my question is that if you as a teacher do you sorry, is it wise to somehow discourage those traits of wanting to build the perfect thing just so they can be they can be seen as productive because at the end of the day if you don't get some vision and that means you are you don't get some vision so do you think as a teacher is there something about those artists that you think their niche of productivity where does it fall so the question okay so thinking about the different types I'm a big believer in that component and so I think that ideally you want a culture that has different mindsets as I mentioned I consider myself the first type that's idealistic big vision let's go to Mars type and it's a bit like the flying airplane maybe we don't need that yet maybe we need to start with just the bicycle so there's kind of two parts to it one is even if you have a natural tendency towards a certain type and I don't think it's just about I think it's just all of us right so you get the exact same thing with CEOs and you get some CEOs who have this grand vision and you get some CEOs who are just looking at the piano right and I think it's the same so I think in part like there's a reflective component which is like analyzing ourselves, analyzing our team and saying what types do we have and then there's an acting as if you were the other types then it becomes more of a discipline so like whilst I naturally say I was an artist at heart I never missed advance because I understand that that's important and so I'll have this grand vision but I will just park it somewhere and I'll switch to a different mindset that allows me to plan that better but I think you know there's detriment to each of the kinds so if you never think about that vision, that bigger picture when you get to a point where you finish your run of features or you don't know where to go next as an organization, as a product if you have no vision then potentially you're lost as well so I think you can get lost because you never ship something but you can also get lost because you have no idea where to move in the market I agree but I think it's that maybe you have an actual tendency to run style and you discipline yourself to try the others or you try and build a perfect complementary team of all sorts to keep them in check I think one of my experiences dealing with some artist type thing is is that because they seem to not they seem to not able to stick to the premise that we did about the product that you did there's one example in which we decide or we let them to decide how much time do you need to do this and somehow they seem to stick to it better even if we estimate themselves are not really conservative but they don't ask for two months to do something that other engineers still needs but it's just that I'm wondering if we doing that to them, it makes them stick to timelines better but are we as product which if we do that are we training are we training out something that's actually good for companies and so I guess so like do you think in some aspects that artists, engineers need if we can get the best we need to somehow train them to stick to the premise to do that like determine them in some way or would they use something by I wonder if anyone else wants to join in the discussion you said just engineers of course like designers I think are one of the most I think liable because designers be more professional they are more perfectionist than they may be what's the question it sounds a bit like time estimates so I guess it's like I said about some engineers or some I think not able to stick nothing ever seems nothing seems to get done in time and my question is if we if we try to discipline them to be more to stick to the timelines by all methods are we actually are we demoralizing them or are we training something out of them that's actually beneficial for the companies can I try to answer that question have you considered that making your engineers a bad I think I think that's a pretty long stretch there the only thing are you doing, are you agile are you smoking stuff correctly bigger stories broken down that's why agile is to me different the other way is to try to figure out what to do with them and maybe then the greatest goal for him or her but yeah things like that they should come up with their own estimates of the effectiveness yeah I think there are a number of factors there's so many reasons that could be contributing to it I think they can part your question with that if you just crack the whip and like just force everyone force your engineers to just be robots and are you losing some value for policy and I think that if there are parts ways in which they're trying to contribute towards the culture of your organization or division of your product then I think you want to try and capture some of that and perhaps it's just you need a separate vessel to capture something like I think the conversation between product and tech need to see from day one day zero I think it shouldn't be a case of just stuff getting dumped in tech but I say that as an engineer I hate it when I just see stuff like the day before I meant to build it I like to be involved in that process I'm sorry how big is your integration? it might be more than that that's your whole involvement but my team I'm going to put it in between designers, strictly designers just get rid of all you can I'm not trying to solve the problem just give me a second so I think for project managers you usually have to break down the user storage so they don't take more than a day to complete what is the culture so I think what our company do I'm from Inbox Studios currently currently I'm doing data management so I think what we have recently incorporated is that every time or every start of the week you have like a scrum session talk about things together and then we'll have number cards together and the developers will suit together as they make how many hours to take and then you sort of take the average ten for your two project managers three designers five engineers oh no, ten engineers oh okay so more than I think usually with Google it's like a one to ten or one PM to engineer ratio probably have to be a product manager product manager probably not an engineer actually having been a product manager around running code as well it's easy to come up with stuff it's hard to build tell us about the interactive teddy bear oh yeah maybe do you already want to know about that yeah I don't know maybe you guys don't get it in the UK we've got a TV show for Dragon's End and that's why people don't get their ideas in that sort of thing yeah same as at Shopping maybe I should talk about it it's my name is M.D.O. you guys can't miss the run walking around and might stumble in so you might have to shuffle in a bit if you get more people