[Tech talk] “The Future of Product Development” by Jean-Michel Lemieux, Vice President of Engineering at Atlassian
•Download as PPTX, PDF•
7 likes•1,160 views
“The Future of Product Development” by Jean-Michel Lemieux, Vice President of Engineering at Atlassian. What you will learn: - Evolution from writing code to "product creator" - Importance of design and usability in product - A transition to scientific development: Usage analytics and Experiments driving roadmaps - Why our latest JIRA team will be based in Vietnam
Recommended
More Related Content
Similar to [Tech talk] “The Future of Product Development” by Jean-Michel Lemieux, Vice President of Engineering at Atlassian
Similar to [Tech talk] “The Future of Product Development” by Jean-Michel Lemieux, Vice President of Engineering at Atlassian (20)
Recently uploaded
Recently uploaded (20)
[Tech talk] “The Future of Product Development” by Jean-Michel Lemieux, Vice President of Engineering at Atlassian
- 2. Where everything started Talented people in Vietnam to build products and to build them differently
- 3. One year & half ago… And a core team of 10 working on
- 4. … since then … 6 innovation days 3 awards from our customers 30+ features and improvement requests fulfilled 1000+ customers votes satisfied 60 people
- 5. … and later on. Performance Security SaaS Customer Platform 150+ people Awesome new features And a whole lot more…
- 6. What makes Atlassian awesome 3. Office & working environment
- 7. What makes Atlassian awesome 2. Atlassian values Open Company, No Bullshit Build With Heart & Balance Don’t #@!% The Customer Play, As A Team Be The Change You Seek
- 8. What makes Atlassian awesome 1. People I’m working with everyday
- 9. And…
- 11. Where’s the Product Gene? Jean-Michel Lemieux VP of Engineering @jmwind
- 13. http://www.acm.org/education/education/curric_vols/CC2005-March06Final.pdf CS Working and reliable computer programs SE Efficient software process and computer systems PE Desirable products and ecosystems CE Build and design computer “square wave” hardware EE Build and design electrical “curvy waves” systems Degree One-Liners
- 15. Product Engineering Manifesto Products over Software Experiences over Functionality
- 18. What are the basics? Algorithms Data Structures System Admin Programming Languages Compilers Storage Networking Architecture
- 19. Teach the basics Earlymath math math math geometry calculus physics chemistry algebra natural science geography programming data structures algorithms
- 22. Learn to play as a team to build desirable products and ecosystems for your customers that will last for years. Degree Elevator Pitch
- 23. Customers First customer journeys personas win shipit interviewing customers
- 25. Personas
- 27. ShipIt Define the problem Tell a Story Make it work Sell with passion
- 28. Build for Desirability hypothesis driven development ui reviews design guidelines micro-interactions
- 29. Hypothesis Driven Development Smarts Bias
- 30. Hypothesis Driven Development Science 101 Hypothesis Generation Experiment Design Cohorts Experiment Deployment Measurement & Analysis Results Publication
- 33. Reviews
- 34. UI Peer Reviews
- 35. UI Peer Reviews Learn to See Learn to Seek Consistency Contrast Bring Forward Alignment Simple Speak Human Don’t start from Zero Prevent Mistakes
- 38. Build as a Team “open” by default code archeology peer reviews roles (design, pm, qa, marketing) basic agile
- 39. Share earlier than your gut tells you to… It’s a relay game… don’t be a hero!
- 40. CORESAMPLES
- 41. TEAM FINGERPRINT
- 42. WEATHER PATTERNS
- 43. TIME IN CODE
- 44. Grown an Ecosystem api first design for extensibility make your tools available open source, licensing, ip
- 45. Extensibility is Hard APIs and Extensibility
- 46. Build like your customers
- 47. Do I own my ideas? CLAs
- 48. Build to Last for Years security you build it, you run it pipeline: testing, deploying, and monitoring data survival maintaining and evolving large code bases
- 49. How to paint an airplane while in flight? • Don’t trust test data • Migrate data in 5 steps • Validate assumptions in prod • Think likes an “ops” person • Starts from an existing code base • … +100 other learnings
- 50. Customer Journeys Personas ShipIt Interviewing Desirable Hypothesis Driven UI reviews Design guidelines Micro-interactions Team Open by default Team archeology Team roles Agile basics Ecosystem API first Design 4 Extensibilit Open tools OS, Licensing, IP For Years Security You build it, you run it Software Pipeline Assume it will break Code Migration/Evolution Product Engineering - Year 1
- 51. Learn to play as a team to build desirable products and ecosystems for your customers that will last for years. Product Engineering - Year 1
- 52. Product Engineering Manifesto Products over Software Experiences over Functionality
- 53. THANKS!
Editor's Notes
- Thanks Quyen. Good evening everyone, thanks for joining I will take 5 min of your time to explain a bit how we all ended up here tonight Atlassian came to VN, looking for talented people to build products & to build them differently Differently because Atlassian is not looking for an outsourcing model Differently because the teams have to be fully integrated with the other teams around the world and yet autonomous And differently because the team work will have an impact on million users around the world
- One year & half ago, Pyramid Consulting started helping Atlassian in building their new R&D office in Vietnam And the 10 members of the new VN team started building new features for Confluence
- Since then The team grew up to 60 people We took the ownership of two major plugins of Confluence We onboarded a new team working on JSD More than 30 new features & improvements requests were fulfilled while satisfying more than 1 thousand customers votes We participated in 6 innovation days &, among all the projects, we were awarded 3 times by our customers
- That’s good but we are aiming to even bigger & better Soon, we will onboard a new team working on JIRA Some other teams will join the adventure (Perf, SaaS, CPT, Security) In 12 months from now, we will be more than 150 We will build awesome new features and a whole lot more…
- What makes Atlassian awesome I know this subjective but I will share with you my personal TOP3 3rd place: our office, and more globally, our working environment Work hard, play hard. And we have what we need to do both. The working environment is awesome also because of the 2nd reason…
- 2nd reason: Atlassian values As a former consultant, I worked for a lot of different companies around the world. Atlassian is the first place where I see the company values shared by everyone & living in everything we do. If you never heard about them, here they are OC,NB BwH&B D#tC PaaT BTCYS And my TOP1 is probably a consequence of living those values everyday
- I love working with people in Atlassian Everybody shares the same passion of building awesomeness, of improving everything and of sharing/discussing to make it right Actually, there are 2 other common factors in our team The 1st one is what we call T-shape A deep knowledge in your own specialty/discipline while having a broad knowledge on other domains Like a JAVA expert knowing a bit of FrontEnd, UX & Analytics
- The other common factor is what we call “the product gene” but I will let my friend Jean-Michel give you the detailed explanation Thank you very much
- Prepared by JML for a keynote in the ASWEC 2014 education track.
- Don’t get me wrong, I loved university (I found the a floppy with two of my 4th year programming assignments!). I learned a lot and made life long friends. Looking back, it’s hard to think of course that didn’t add to my toolbox and helped me grow and tackle all those challenges that a career in software development will throw at you.
- Computer scientists are primarily concerned with the design of algorithms, languages, hardware architecture, systems software, applications software and tools. Applications range from simple game playing to the control of space vehicles, power plants and factories, from banking machines to intelligent fault and medical diagnosis. Computer professionals, in short, are concerned with the creation of computer and information systems for the benefit of society. Software engineers learn much more about creating high-quality software in a systematic, controlled, and efficient manner. Software engineers are trained in all aspects of the software life cycle, from specification through analysis and design, to testing maintenance and evaluation of the product. They are concerned with safety and reliability of the product as well as cost and schedule of the development process. Product Engineers built on both computer and software programs but cater to the evolving ubiquity of software. Whereas in the past it was powering machines and middle wear, it’s now powering every product. Consumer, enterprise, most human beings will interact with a software product every day of their lives. As such, making desirable (eg, functional, quality, easy) products is no longer a nice to have but the norm. It’s also not just a track in an existing degree, it’s a way of thinking and a specialty like podiatry is to medicine.
- Before we introduce the curriculum let’s establish some of the key terms in product engineering as they differ quite a bit from the current computer and software engineering courses. Here’s an example using the tag clouds from the websites of UNSW, USyd, and my university in Ottawa Canada. You’ll notice that the worlds products, experiences, shipping, customers/users don’t appear anywhere?
- But as I’ve grown through my career, there are two fundamental areas in which I had to get better that I wasn’t taught in school. These are things that are the foundation for product companies, and more generally for entrepreneurs. Products move the focus from systems to customers. You’re ultimately building something to make someone else better and building products is never just about the software. It’s about the way you market it, the ease at which your customers can onboard, etc.… The next focus area is around experiences. The “done criteria” for products is not just being good but being great from an experience perspective. The personality of your product and in a consumer world a “good” product experience isn’t enough.
- Many have proclaimed that the “product gene” is something you’re either born with or out of luck. Only certain people have these elusive product skills. Well, that’s crap. Our hypothesis is that we haven’t been able to teach it yet. In addition, we have a couple of examples in Atlassian with either new graduates or new teams growing very quickly and building out this product gene muscle. While it may come more naturally to some than others, we’ve debunked the “product gene” myth. I’ll show you how…
- To be clear, all degrees require programming knowledge and experience. I’m not advocating changing this in anyway.
- You can’t skip these basics… there isn’t a single class from uni that didn’t help me be a better developer. Every single one really help develop skills and knowledge that was useful at different times in my life. Surprisingly, in software specifications course our teacher told us about communication. The soft-side of programming in language and how ambiguous it can be … as an example “my house flies like bananas”. This stuck with me for my entire life, help write API specs, better e-mails, etc…
- But instead have to teach the basics earlier. Estonia has already integrated computer science into primary school and it’s the only way that we can evolve the university programmes. Students learn math from pre-school and there is no reason why we couldn’t cover most of the basics before they start uni and give them many hours of hands-on experience.
- Who here thinks that there is 3 years of material in a “product engineering” degree? Well I do, so let’s take a peak into a proposed programme for the degree.
- The product engineering curriculum is built around 5 key themes. As you saw from the word clouds, note of these words appear in the academic description of computer science. These words were inspired by how we introduce graduates to Atlassian. How we explain the key mental shifts they will make by becoming product development ninjas.
- The elevator pitch for the course integrates the 5 themes.
- The first theme is about putting your “customers”, “users”, or more politically correct the “people” from at centre of the design process for the software you’re building. The mental shift is going from a viable first development mindset to an experience one and as you’ll see, this isn’t just for designers.
- First area of study is the user funnel through a product. It matters because every feature you build is in the context of their flow… is the feature something that will help them convert or decide how to engage with more users, or is the feature going to help them discover how best to use your product? As importantly, most success metrics for products are related to metrics which affect one of more of these journeys. Talk about the OnDemand licensing example: developers given a job to allow each product to be purchased separately, but focused too much on the technical aspects. But ultimately the feature was about improving 2 key metrics: conversion and cross-sell. The development team didn’t provide a way to return to the ordering/catalogue page from the product thus making cross-sell extremely difficult after all their hard work on the cool licensing changes.
- Like Mohamed Ali said, “hit them where it hurts the most”. We use personas to help empathy but also understanding of our users and be we are creative about how we spread the word about our customers.
- consistent remove as much as you can invent with care be a human
- You can hire two kinds of developers, smart or creative. The smart ones will create great software, the creatives will create the right software and prevent 1/5 of it from being written in the first place.
- consistent remove as much as you can invent with care be a human
- consistent remove as much as you can invent with care be a human
- consistent remove as much as you can invent with care be a human
- learn to see, learn to noticed, learn to seek, learn to remember. consistent, remove as much as you can, invent with care, be a human crap: contrast, repetition, alignment, proximity
- learn to see, learn to noticed, learn to seek, learn to remember. consistent, remove as much as you can, invent with care, be a human crap: contrast, repetition, alignment, proximity
- When you write software, you are creating a kind of property. By default, this property will be owned by somebody. If you are an employee, it is likely that your employer will own the software you create in the course of your employment. If you are working for yourself, or working in your free time on matters unrelated to your work, then it is likely that you will own it.
- But as I’ve grown through my career, there are two fundamental areas in which I had to get better that I wasn’t taught in school. These are things that are the foundation for product companies, and more generally for entrepreneurs. Products move the focus from systems to customers. You’re ultimately building something to make someone else better and building products is never just about the software. It’s about the way you market it, the ease at which your customers can onboard, etc.… The next focus area is around experiences. The “done criteria” for products is not just being good but being great from an experience perspective. The personality of your product and in a consumer world a “good” product experience isn’t enough.