Rian designs and builds high quality software that people love to use. He also wrote a book about it called Making It Right. After spending several years working in Silicon Valley and Cape Town, South Africa, he is now Product Manager at Wildbit, working from Portland, OR. He blogs and tweets regularly about design, technology, and software development.

Follow Rian on Twitter

 

Episode Transcript

J Cornelius: Big companies like Ikea and Salesforce trust Postmark to deliver millions of emails every day. Today, their Product Manager will tell us how they use smart project plans, rapid prototyping, and user-testing to keep things running like clockwork.

Intro: This is Design Driven, the podcast about using design thinking to build great products and lasting companies. Whether you're running a startup or trying something new inside a Fortune 1000, the tools, methods and insights we talk about will help you create things people want. And now, your host, J.

J: Hey, everybody, we are excited to have Rian from Postmark with us today. It's just Rian, kind of like Madonna or Prince who's really great at what they do. We're really fortunate to have him on the show today. Hey Rian, how you doing?

Rian van der Merwe: Good, thanks J. I do have a last name, it's just really difficult to pronounce, so don't worry about it.

J: No, it's fine. We were talking a little bit before the show, and you mentioned that there's a couple different pronunciations. So where are you from, and how'd you get to Postmark, and what's going on over there?

Rian: Sure. I'm originally from South Africa, I grew up there. Studied there. Did an Engineering degree, and then after that I moved to Australia to continue my studies. How I ended up in the US is kind of a story about a girl, as it sometimes is. I met my wife there, and it sounds really creepy when I say it like this, but I followed her back to the US because she was from San Diego, but it ended up working out fine. I don't know how the story would have ended if it didn't work out fine, but we ended up getting married, so that's when I moved to the US after my studies in Australia.

I started my career pretty much right away at eBay. I was at eBay's user experience research team for a long time in the Bay Area, and then I moved to a startup, and moved back to Cape Town. We moved back to Cape Town, South Africa for four years. Did a bunch of product work there, design work, also some agency work. Then we decided that it's time for a change, so we picked Portland out of a hat, no real reason, it just sounded like a cool place, which sounds so scary now that I say it out loud. But we moved here.

I worked in a couple of places in healthcare and things like that. I've been at Postmark now for almost a year, and hope to ... I'm what I'd like to call a Wildbit Lifer. Postmark is made by a company called Wildbit. We make tools for developers, and it's a fantastic place to work and to do great work. My current role, as the product manager at Postmark is the first official product manager that Wildbit has hired, so it was kind of a long hiring process, and lots of discussions with the founders and catching up and talking about things, because I think that's one of the big things I always notice when startups hire their first product manager, it's a really scary thing, because we tend to be strange. It's a role that I think is absolutely essential, but it's such an intimate role with the product and the founders that they have to take really good care of who they hire, so it was kind of a long process. But we're about a year in and it's going really well.

So, Postmark is a transactional email platform. We're an infrastructure for websites and applications that send transactional emails. So those are your triggered emails, like password resets and common notifications, welcome emails. Those really mission critical-

J: Anything that's not a marketing email, right?

Rian: Right, so we explicitly don't allow marketing or bulk email on our platform. We can maybe talk about that a little later, but it was very much a strategic decision on the company's part, because we feel like our best feature and our biggest feature that we want to focus on is our deliverability, and the speed with which we get our emails to the inbox. If you throw marketing email into the mix on that, it gets a little harder for your IP's reputation to stay really good, because you get more spam complaints, you get less engagement with marketing email, all that kind of stuff.

So we focus exclusively on email that you would consider mission critical for your app, email that cannot get lost. Where a single one can cost you money, those are the emails that we focus on.

J: Yeah, like lost password, account confirmation, order confirmations, those things that people really rely on to make sure that something happened and it's actually working, right?

Rian: Exactly, and not just they need to get it, they need to get it quickly. If you wait 30 seconds for a password reset email, you start to get a little antsy.

J: Yeah, you start to get frustrated.

So, what is your day to day work look like there? What types of things are you doing, what type of feedback are you collecting from customers? How are you making decisions about the product? Kind of walk us through what that looks like.

Rian: Yeah, we're a small team. We have a couple of designers, one product manager, and about four or five developers who work specifically and exclusively on Postmark. The role, as with most product managers roles, has shifted a little bit over the past year. When I first came on, I was lucky enough to start just as we had our first yearly company retreat.

Wildbit is a remote-first company. Half of the team is in Philadelphia, in our head office in Philadelphia, and the rest of us, including me, are spread all over the world. So we get together once a year as a team. I started a week before that. We spent that week basically doing a bunch of product discovery, which is what I think we'll talk a little bit later in detail. The first six months of my time at Postmark was mostly centered around figuring out our strategy and our vision going forward, so understanding the problems that we're solving for customers, coming up with our target market and personas. I know personas can be kind of a dirty word, but we actually use them, because we use them to narrow down who we're actually for, and who we're not for which is the part where I think personas can be really useful in terms of making product decisions.

J: Yeah, so if you think of a persona as a market segment, or a customer group, instead of the word 'persona' it's essentially the same thing, right? So you who are you making something for, what are they trying to accomplish? What are their pain points, what are they looking to gain? All that stuff.

Rian: Yeah, the reason I still like the word 'persona' even though it's fallen out of fashion a little bit is that it's focused on the product decisions we want to make based on who that target market is, because if you talk about target market, it becomes a lot about messaging and brand positioning and stuff like that. Persona is helpful for that too, but for us we really use it for product decisions as well. If there's a request that comes in from a customer and it's not in our target persona, it makes it easier for us to make those decisions.

J: Yeah, that makes sense. So in those personas, are you also using a tool, like a value proposition canvas, to understand how a particular persona or group's needs are mapping to specific product features?

Rian: So, we're using customer journey maps for that. As part of that first week we had, and as part of product discovery, we came up with the current customer journey, and then an ideal customer journey map of how we want things to go online, as well as offline. So this included how people would find out about us, all the way through integrating with our app, as well as our drip campaigns, our onboarding, all of that stuff.

Then, when we worked on personas, those are mapped to those specific journeys. Especially in the beginning when we came up with our longterm strategy, that we're bound to revisit now that it's a year in, we looked specifically at which personas we want to focus on, and then which parts of the customer journey do we need to focus on the most for each of those personas.

J: Interesting. So do you redo the map on an annual basis, or how often do you revisit that?

Rian: Kind of skipping ahead and back. I wouldn't say we're going to redo the customer journey map when we map, but what we will do is say, "Is this still correct? Is this still where we want to go? Is this strategy and vision we came up with still who we are and what's most important for us?"

Most of the time, for most of those things, it's going to be yes, because we catch up every week about our priorities and stuff, so there's nothing new there. But what will probably change is which part of that journey we focus on, like the onboarding has been a big focus for us at the moment, so it's possible that we might shift into areas of the app later on in the process with integration, or maybe earlier on in the process with how you find Postmark, and how we define who we are.

So that's what we do in our quarterly planning as well. We look at that customer journey map, we see where we are, and we revisit our priorities for that.

J: You said something that was interesting. You do that kind of on an annual basis, and then you have quarterly journey map revisions, or quarterly meetings to review that, but then you said you also get together weekly and make sure that everything's going on. So are following an agile methodology, or are you just having weekly stand ups to make sure things are on track? How do you make sure that things keep moving in the right direction.

Rian: Yeah, so that's a really good question. I think it's a big goal for us not to turn ourselves into a big company, and that's something that I'm still trying to adjust to. We try to keep meetings to minimum, since we're all remote, or most of us are remote, but we try to then be extremely efficient in those meetings.

How this all cascades down is we have our quarterly planning, where I usually go to Philly, and we get together and discuss this as a leads team, so the lead developer and the founders, and we discuss those priorities and what we learned from customers during the quarter, and we kind of come up with a rough plan. We don't come up with dates, we come up with our list of priorities that we want to work on, the things that are most important for us to work on. Again, we might change some of this, and now that it's a year in, we're actually thinking of shortening that to maybe six or eight weeks. Right now, those are quarterly planning cycles.

I pretty much have three meetings in a week and that's it. On Fridays we have our weekly check-in as a leads team, where we discuss general strategic stuff around the product, but also how our project's going. Also, is there anything new that we need to talk about? Because roadmaps shouldn't be static. If it's static you're in trouble.

J: Yeah, good point.

Rian: So, I think a lot of the reason why roadmaps have a bad name is that they're set for six to nine months and then you're just stuck on them. So we would never stop work ... I shouldn't say never. We would extremely rarely stop work mid-way, but we would say, "Oh, there's a new thing that's really important, so after we're done with this, that thing needs to come higher in the priority list, and something else needs to move down."

So, we use that meeting to make sure that our priorities are still aligned. Sometimes it's a five minute meeting, because we just go, "Yep, everything's still the way it is," and sometimes it's an hour and a half, as we discuss some things.

Then, on Mondays, we have an OKR meeting, where we follow objectives and key results, and particularly we us a matrix that Christina Wodtke talks about in her book Radical Focus. That gets the team aligned. It's basically, these are objectives and key results, and this is our confidence level that we're going to meet those objectives and key results by the end of the quarter. We talk about health checks, so we have certain metrics in place for the product, things like how fast do our emails get to the inbox? How good is our throughput? What's our performance like? That we just check on and make sure that everything is still good where we want it to be. If it's not, we talk about it and might make some adjustments. That's our side of the matrix.

On the other side, we discuss with the team, these are the things we want to get accomplished this week, and these are the releases that are coming up in the next four weeks. This is a meeting with the whole team. What this does, is it helps everyone, including customer success and marketing prepare for launches that are coming, and it gives us stakes in the ground to say, "Here are the things that we really want to get done this week, and that needs to get done this week if we still want to meet our OKRs."

What's a little different about this, is we don't have release dates until we're about four to six weeks out. Unless of course it's just a week long project, then we have it.

J: So are you releasing every week?

Rian: We release when we're ready. That's what I'm trying to get to, is we're one of those spirit of agile companies.

J: Right, right. So it's not a continuous integration thing as much as, when you've got a feature ready to go, you start mapping its release?

Rian: Yes, and we deploy when we're ready. There's no specific, we need to wait until this cycle is done, or until this sprint is done. We work on our priorities in order, and when they're done, we QA them and release them. Sometimes things go together, and there's dependencies and all that stuff.

Instead of saying ... We were talking about this this week, when it comes to release planning, there's three different ways. One of them is really bad, and the other two are really good.

The first one that's really bad is when someone says to you, "We have to release this by this date," because then your scope and your dates are fixed. The second way is to say, "We want to release this, how long will it take?" So, the scope is fixed and the date is not. The third is, "We want to release something by this date, what can we get done?"

We're following kind of a combination of the second and third, where we really say, "Okay, this is a piece of work that we want to get done. We think it's going to take six to eight weeks, so let's start working on it." Then at some point, as you go, you might be two weeks in and realize, "Oh, there's an infrastructure piece that we didn't account for, it's going to add two weeks to the project," and then you have to decide. This again is where our leads meetings come in. Then you have to decide, do we add two weeks to the project, or do we cut scope out of it so that we remain in our six week cycle?

J: Right. I guess that depends on the scenario, but what kinds of things are you thinking about when you're making a decision on whether to push back the release or scale back the scope?

Rian: At that point it comes to the value that it provides to the business, and the other work that it would push out. If something is crucial for the rest of the business to work on, or to continue with, we might stretch out the timeline and just get it done. If we need a developer to move on to other things, we'd figure out how do we need to reduce the scope to still have something useful and valuable, and then leave the rest of it for a later phase. It's one of those art-type things, where you-

J: It's really on a case-by-case basis, right?

Rian: Yeah, very much. As I'm talking you, it sounds kind of chaotic, but it really isn't. I think it's more chaotic when you say, "we have this release date and these five things need to be in it." One of our core principles at Wildbit in general is to say, "We want to continue to increase our efficiency without increasing our stress levels as well." That's really important to us, that we are happy as a team and enjoy the work that we do. This is part of that, to say, "Okay, no one's in trouble when this thing is going to take two weeks longer, we just have a decision to make. Is it going to take two weeks longer, or do we cut some stuff out of it?"

J: Sure, and the opposite, when you've got a fixed scope and a fixed timeline, is pressure just continuously increases until you blow past the timeline inevitably.

Rian: Everyone feels bad.

J: What I'm hearing is by having weekly check-ins, and making sure that everything is staying on track in terms of either scope or timeline, you have kind of a pressure release valve that happens at each of those weekly check-ins to make sure the team stays sane and the project stays on track.

Rian: Yeah, and that's where Christina's OKR matrix is really useful, because you have ... I really recommend this book. She talks about this confidence level. Every week we say, "What is our confidence out of 10 that by the end of the quarter we're going to meet these goals?"

She says these goals that you should set for yourself, the objectives and the key results, should start of in the beginning of the quarter. Your confidence should be five out of 10. It should be hard enough that you're going to need to stretch yourself, but not so hard that you will never be able to do it. This took us a couple quarters to get right, and we're still learning, but we start off with, we have a five out of ten chance to make this, and if you're two weeks to the end of the quarter and you're a two out of ten, you know something needs to change. That's when you change the timeline or change the scope.

Ideally, two weeks out, you're at eight out of ten. Barring some kind of really bad situation, you're going to be able to make that.

J: Right, you should have a high level of confidence that you're going to-

Rian: - By the end of it. Right, yup.

J: That makes perfect sense.

Can you talk a little bit about the tools specifically related to design systems or reusable bits of infrastructure, or code, or things that make it easier for you to scope and work on the actual problem instead of reinventing the wheel each time?

Rian: Yeah, so we use the usual suspects in terms of tools to get our work done, Slack and all that stuff. We do use InVision in the beginning in the design phase of a project to gather feedback from each other, but then we started doing usability testing as well on prototypes. Those prototypes are high fidelity prototypes. Our developers are front-end developers as well, so-

J: When you say high fidelity, do you mean it looks just like the actual web app, or is it a little bit less?

Rian: It looks just like the web app, it's not throwaway code. It's code that becomes production. So before you freak out, let me explain. I know there's all these trade-offs about, okay, so there's lower fidelity stuff, it's much easier and quicker to make changes. If you do it too high fidelity and there's a problem, it becomes a big issue to make changes. But for us, what we found is if we do our work right ... We do RITE test, so Rapid Iteration Testing and Evaluation, so we do three or four usability tests, then take some time to make changes, then do it again, then take some time to make changes, then do it again. So we don't do five or six usability tests and then it's done, and then we have to figure it out. We make changes as we go, because for us as a small team, the outcome of our usability testing isn't about going back where we need to convince some VP of product that we know what we're doing. We're a small team, all we need is better software, and we need to improve our software. Once we're-

J: It sounds like you're doing it very iteratively.

Rian: Yes, so when we're out of the InVision phase, our designer would build a functional, high-fidelity prototype that we would then take into testing, and after each day of testing, we would discuss this and he would go back in and make changes as we go. At the end, what we have is, if we did our jobs right, a high fidelity prototype that needs a few more days of work, and then can get integrated into the app.

J: So, are you taking the markup directly from your InVision prototype and moving that into production?

Rian: No, the InVision prototype is static. The prototype is getting built within our app, basically.

J: I see. So you're moving it from a prototype in the app to InVision for testing, and then forking that off and moving that into production code.

Rian: No, we actually do testing on the interactive prototype, not in InVision. InVision is just for static markups for us internally.

J: I see. Okay.

Rian: Then the prototype we build, we make accessible externally. We do remote testing over video conferencing software called Zoom. We would then share this URL with customers, and it's accessible to them. They can play with it. There's obviously nothing hooked up in the back-end, but it's fully interactive for them.

J: Right. No, that's good. So it's kind of like having a staging environment that's sandboxed away from your production back-end just to do the testing with actual people?

Rian: Exactly, just like that.

J: Nice. So how do you select who you're going to test with? Is that segmented by personas, or what's going on there?

Rian: So, that's another trade-off thing. Ideally, for a lot of our projects, ideally what we would do is hire a recruiting firm, pay them a lot of money, come up with a recruiting questionnaires, all that stuff. What we do instead, because we want to do it quick and stay scrappy, and move quickly through iterations, is we have a list in Campaign Monitor that people can sign up for who want to help us with this stuff. On a regular basis, I would email that list and say, "Here's what we're going to do some testing on. If you'd like to participate, pick some time on the calendar." So they are our customers. What we lose from that is a little bit of bias from people who already use the product. What we gain from them is a lot of speed.

I've done this both ways. At eBay we had an internal recruiting team, and I haven't really found that the results we get are of low quality. The reason for that is our RITE testing is focused on task-based usability testing. It's not, what do you think of this logo? It's, here's a task you need to perform. You need to sign-up, you need to check out, you need to do whatever. Because it's observational task-based usability testing, making sure that we have the exact right target market person becomes less important, because it's harder to fake, and the bias is kind of taken care of, because it's observational.

J: Yep, exactly.

Right, and all those people have already opted in to test the app for you. So there's no recruiting needed.

Which is nice, because you already have a user-base to pull those people from. Rather than go out and try to find people externally, which actually brings up an interesting point. If you've got people that are already familiar with the application, how are you testing things like onboarding for new users and making sure that that process is efficient?

Rian: We just did this actually. We were testing a new signup process. What's interesting about our product, is the people who we ended up testing with either signed up so long ago that they can't remember what it looked like, or they weren't actually people signing up. So this is what often happens, is some kind of manager or IT manager person would sign up, and then create accounts for their developers to actually be in the app, so the majority of the people we've tested haven't actually gone through the signup process, because they were just handed an account and said, "Here you go, go play around."

We try to account for that at least, in our recruiting, that either enough time has passed, or we test with people that haven't used that particular feature before.

J: Yeah, well, it's good that you're paying attention to that. Try to remove as many bias as possible, right?

Rian: Yeah, yeah exactly.

J: So, are you using design systems, or a style guide or anything? I mean the app is already pretty mature, so I'm assuming you've got a lot of that stuff in place.

Rian: All I can say is really want to, and we have this huge list of ... We have a design system project in Jira, I promise. Every quarter the designer and I are like, "this quarter we're going to get to it."

The furthest we've gone at the moment is to have an internal voice and tone guide, specifically for the app and interactions in the app. So what the buttons should say, and how to speak to customers in direct one to one communication, including how the app should sound.

J: For things like error messages alerts and so on?

Rian: Correct, that and action buttons and how that should work, and all that kind of stuff. As we redesign certain areas of the app, it becomes more consistent, because of the way that it's implemented right now. We recognize we have a need for a design system to make those things easier, so it's one of those things where I'm embarrassed to say we're still working on it.

J: But you recognize the need, right? It'll be interesting to see what the implementation of a design system does, and how that impacts your production cycle, your day to day work, and what kind of relevance that has for your customers using the application. Do they notice a difference?

Rian: Yeah. We've gone so far as to do a bunch of the audits we need to do in terms of button styles and all that stuff. As is usual with an app that's been around for a while, yeah, there are some inconsistencies there, but what we try to do is fix those every time we touch that app, so error messages become more consistent as we go, buttons become more consistent as we go.

J: There's a continual improvement.

Rian: Right, yeah. It's interesting to work on an app like this where people really love it. I'm not saying that as ... I'm not in Marketing, so I'm not trying to say anything weird about it, but our users are developers, which first of all means that the feedback that they give is incredibly specific and passionate. But second, we ... Before I came here, so I can't take credit for this, but the team really focused on the right areas for the product. They realized what's really important is this deliverability issue. It's a product that's really successful already, so that changes how you do product management and design on a product like, because there aren't these obvious gaps and obvious things that needs to be fixed. Everything we do is iteration and improvement. It's not a bad problem to have, but for us there aren't these giant gaps we need to fix. It's all about how do we listen to customers in the right way, and how do we add the features that are going to be most valuable to the most number of people in our target market.

J: Yeah, it sounds like that early on the product was focused on users' goals, and what their pain point was, and deliverability was the highest pain point, right? You want email to be delivered accurately, reliable, and very quickly, right?

Rian: Yeah.

J: So if you solve that problem, then a lot of the other problems become secondary. As long as you're doing a great job on deliverability, then you can focus more on having good voice and tone, like you were saying, or having a fun, playful interface, or whatever those secondary things are.

Rian: Yeah. We're big fans of the jobs to be done here as well, so we're currently redoing our homepage to focus a lot more on that as well. I look at some competitor sites and it's very much about them, and we want to try to make sure we solve customer problems. For us, one of the big messages in the new landing pages is, "Are you tired of missing or delayed emails? Because if you are, that's where we're from. We're going to show you live data of how long it takes emails to get to the inbox."

All that stuff is consistent with this message of, if you're sending emails that are really crucial to your app, do this. Use us. But it doesn't mean that it's done. There's so much to do, right? There's a design system. There's areas of the app that can have definitely improved usability. And those are all things that we'll work on. It's just interesting to work on a product where the next thing is not as obvious as it sometimes could be.

J: Yeah, so speaking to the users' goals first helps them understand that you have their best interest in mind. Obviously the product is doing what it needs to do, and then you can focus on all the things that make the app. It's kind of like Maslow's hierarchy, right? So you've made it usable, you've made it desirable, and now you can make it fun, right?

Rian: Yeah. I think about the Nielsen Norman Group definition of usefulness, that it's about both utility and usability, and we sometimes focus on one or the other. There can be extremely usable products that serve no purpose, or there are lots of products out there that are extremely useful but really hard to use.

J: Yeah, or the difference between being functional and being beautiful, right? They're not mutually exclusive.

Rian: Right. So I think for us, we know we have a product with lots of utility, and we can improve that utility with features, but there are also areas where we can improve the usability to make that a more enjoyable experience. That's what we're focused on. As long as we continue to be able to scale our most important feature, which is our deliverability, we create room for ourselves to also improve the usability.

J: Yeah, so you're keeping an eye on the ball, so to speak, with keeping deliverability high, and then focusing on everything else.

Rian: Yeah. I think more than anything ... Maybe more for us than other companies, that key discovery of what our users really need is extremely important for a product that feels as mature as Postmark does, because it needs change over time. We might see a cool technology, and think oh, we should try this, but no one has that need. That's another reason why the usability testing that we try to do very frequently is so important, because it's an opportunity for us to speak to our customers in real time. I have a calendar link that any one of our customers can set up a call with me at any time, so I try to talk to customers every week. I think that's the really important part to make sure that we don't get off on some kind of tangent and not stay focused on what is core, which is what are our customers' real user needs?

J: Yeah, that's really powerful, that a product manager is so accessible to the people that are using the product. That's a great lesson, and something that a lot of other people I think should try to learn from and should try to do, is be available, because ultimately you're there to make sure the product is serving the needs of the customers, and if you don't talk to the customers, if you don't listen to them, how do you know if you're doing a good job?

Rian: Yeah. Absolutely. I don't know if it'll work for every product. I think it depends on your target market. I don't think it will work for Instagram, for example, but-

J: Well, I mean, there's a certain scale, right? At some point one person's not able to answer all of those questions, but just the wisdom of being accessible and actually listening to the people who are using the product is really powerful. There's a lot of companies who could learn from that.

Rian: Yeah, absolutely. Maybe with a service like Calendly it could work at a scale of Instagram, because you can say, "I can't have more than two calls a week," or three, or whatever.

J: Yeah, right. And Calendly is actually here in Atlanta, we've talked to them. I think they're doing a good job, so that's a good example.

Rian: Yeah, I've been a huge fan of that, and just being able to say ... Like, I would jump into support sometimes and just say ... Or just set up a call with me and we can talk about this, because I get so much out of just the question, "Tell me how you use Postmark."

Because what I'm really interested in, specifically again for a product that's as mature as Postmark, is what's happening at the edges. What are people integrating Postmark with that we don't see in our system because they're not using-

J: - Yeah, exactly.

Rian: Because that's where it gets really interesting in terms of expanding the product into its next thing. Let's say for example you're sending not just emails, but you're also sending SMS's for oral confirmations, or whatever. They're not using Postmark for those SMS's, so understanding why people use ... I'm just saying as an example, not that we're going to add SMS, but why are people using SMS, what are they using for it, why is email not enough for them? Those are the questions that I find really interesting, what are the edges that Postmark connects with? I think it's important for every product. I learned this at eBay when we would do a lot of ethnography and in home visits with sellers in particular is there's so much that goes on with selling on eBay that has nothing to do with the eBay sites. People have Excel spreadsheets, or sticky notes on their monitors where they're doing things that they should be doing on eBay, that we could be doing better for them.

The same is true for Postmark, where there's lots of things that people are doing on these edges that we don't know about that could be incorporated into Postmark, and that's what I feel why it's so useful to talk to our customers often.

J: Yeah, right. That's how you map the future of the product, right? Is by listening to what things are right on the edge of what we're doing? What are we touching that we don't see? We call that the Adjacent Possible, what's just right on the edge that we're not currently doing but we could easily add, or we could somehow facilitate?

Rian: Yeah.

J: So what's the future of Postmark look like? What are you working on that's exciting, and what could we expect to see in the next six to 12 months?

Rian: We should have had this call four weeks from now, then I could have told you what our next big thing is, but we have a little bit of a strategic shift going on, not in terms of our core feature, which will always be deliverability, but something else. I want to be like a congressman who's getting asked questions and say, "I'm sorry, I can't talk about that."

J: You'll just have to wait and see, huh?

Rian: Maybe we can do an addendum in a few weeks.

J: Well, we'll just have you back on the show in several months, and you can talk about what that rollout was like, and-

Rian: Yeah, there's so much to say about this. I've been talking to Garret, actually, who you know, about how we want to write about this, because there's so much that goes on, and how do you decide if a small strategic shift ... I'm not going to call it a pivot, because it's not, but a little bit of a strategic shift. How do you decide on that, and if it's the right thing or not? How do you then roll out that across Marketing and Product, that can sometimes ... Like, I don't want someone to get to the landing page and see different language than they see in onboarding, and that often happens in these silos. Again, that was one of my big roles in this, is how can we have a consistent message everywhere?

I would say that there's something very interesting coming in the next few weeks, and after that, I think what's going to be very important to us is just continue to work on scale, because we're seeing some really good growth, and we want to be able to continue to deliver on that promise of fastest delivery and biggest reliability.

J: Well, I'd love to get you back on the show in the future and hear more about that. Since we're about out of time today, any parting thoughts? Or anything you'd like to say before we wrap up?

Rian: Yeah, I'm thinking about what is most interesting to me right now, and what I'm thinking about a lot, and I spent a lot of time on the internet writing and reading, and I've come to this realization. Maybe it's nothing new, it probably isn't, but that we tend to over complicate things. I read this thing the other day about data driven design, and I ended up spending a day redoing our metrics for Postmark, and then I realized this is fun for me, but I don't know if this really helps the product. Not like it was waste of time, but it was ... We over complicate things so much. So when I talk about, we don't have two week sprints, we don't have set dates, it's all in the interest of being efficient without being too complicated.

I don't think I've fully figured that out, but I think it's something that's a real focus for me this year, in particular for our team, and it's something we'll discuss in two weeks when we get together, is, again, how do we increase the efficiency within the team without complicating things and increasing our stress levels.

So, I'm not going to stop reading, and I'm sure that everyone who listens to your podcast reads a lot of new stuff every week, but I think that we need to figure out ... When we read stuff that sounds exciting to us, what are the outcomes that came out of that process or model that someone is talking about, and then simplify it to make it work for you. Just taking something and applying it because it's new is maybe not the best use of our time. That's just what I'm thinking about at the moment.

J: I think that's a great point. I think a lot of companies are searching for, how do they increase their scale, increase their efficiency? Or any of those things. Without increasing headcount, or without increasing stress, right? I think that's a lesson a lot of people are trying to learn, and a lot of companies are working on. Again, I think it'd be great to have you back on again at some point and have you talk about your evolution that process and what you've learned, so-

Rian: Yeah, I'd love to be, because I think over the next few weeks there's this launch, but there's also... The retreat's going to be interesting, because we're actually going to be honest with ourselves and say, "Okay, we have this new process that we've been working on with quarterly planning and all that for a year, what worked, and what didn't work?"

You know, we hear less about that. I wrote a wonderful blog post about how we spent a week coming up with Postmark strategy and vision, but I should also write one about where we are a year later, you know? What did we get wrong?

J: That’d be a good retrospective.

Rian: Yeah, I think it'll be interesting to chat about that again.

J: Cool. So if anybody wants to get in touch with you, maybe learn more about what you're working on or chat with you about it, what's the best way to reach out?

Rian: I think it's still Twitter? I don't think that's shut down yet, right?

J: I think it's still going.

Rian: @RianVDM, R-I-A-N-V-D-M, or Postmark is just @PostmarkApp. Or my email address is Rian@wildbit.com

Or you can set up a call with me on a calendar link that I can probably share with you.

J: Okay, cool. Well, we'll link up your twitter and that stuff on the show notes, so people can go to designdriven.biz, look for your episode and get a link to you there, and then they can reach out, and then you can send them and take it from there.

Rian: Sounds good.

J: Well, Rian, it's been great having you on the show today, I really appreciate you taking the time. Looking forward to the next round.

Rian: Thanks so much, it was real fun.

J: Take care.

Outro: That's it for today. Thanks for listening to Design Driven. We're glad you enjoy the show. Have comments, questions, or an idea that you'd like us to cover? Point your browser to designdriven.biz, and click Contact Us on the top of your screen. We'd love to hear from you. Tell your friends and colleagues about the Design Driven pod, post on Facebook, Twitter, LinkedIn, or send them an email and tell them to go to designdriven.biz, or wherever they find their podcasts. Until next time, remember what Thomas Watson, founder of IBM said, "Good design is good business."