Podio Solutions Podcast

S1E2 - How We Built mPact Pro - Design (Part 1)

January 25, 2019 Brick Bridge Consulting Season 1 Episode 2
Podio Solutions Podcast
S1E2 - How We Built mPact Pro - Design (Part 1)
Chapters
Podio Solutions Podcast
S1E2 - How We Built mPact Pro - Design (Part 1)
Jan 25, 2019 Season 1 Episode 2
Brick Bridge Consulting

Season 1 – Episode 2 – How we built mPact Pro: Designing Wide-Scale (Part 1 of 3)

 

Discussion Outline:

  1. Introduction – We are going to tell a story on how we designed a national product with a 6-figure budget on Podio.
  2. Topic: What were the steps to building an Alpha in 90 days? How was that experience?
  3. 1st Discussion: Consulting & Design
  4. Hot Topic: Why do people DIY Podio builds (or not)? What are some of the pitfalls in not using an agency?
  5. 2nd Discussion: Workspace/App Break-out Design & Data Flow
  6. Real Talk: Limitations – What was the limitation with Podio/GlobiFlow/Zapier that impacted the design?
  7. Deep Dive: Controlling the Discovery Process – Why is the “Discovery” portion so critical in Podio design?
  8. Up Next: mPact Pro – Diving into Beta and the technical side of this 3 part series.
  9. Audience Engagement: Solving Podio Gaps – Podio Developers and Power users – Submit your gaps!
  10. Outro: SUBSCRIBE and Thank you.

Follow us on social media (@PodcastPodio) to stay up to date on all Podio Podcast news.

Support the show (http://www.brickbridgeconsulting.com/podcast)

Show Notes Transcript

Season 1 – Episode 2 – How we built mPact Pro: Designing Wide-Scale (Part 1 of 3)

 

Discussion Outline:

  1. Introduction – We are going to tell a story on how we designed a national product with a 6-figure budget on Podio.
  2. Topic: What were the steps to building an Alpha in 90 days? How was that experience?
  3. 1st Discussion: Consulting & Design
  4. Hot Topic: Why do people DIY Podio builds (or not)? What are some of the pitfalls in not using an agency?
  5. 2nd Discussion: Workspace/App Break-out Design & Data Flow
  6. Real Talk: Limitations – What was the limitation with Podio/GlobiFlow/Zapier that impacted the design?
  7. Deep Dive: Controlling the Discovery Process – Why is the “Discovery” portion so critical in Podio design?
  8. Up Next: mPact Pro – Diving into Beta and the technical side of this 3 part series.
  9. Audience Engagement: Solving Podio Gaps – Podio Developers and Power users – Submit your gaps!
  10. Outro: SUBSCRIBE and Thank you.

Follow us on social media (@PodcastPodio) to stay up to date on all Podio Podcast news.

Support the show (http://www.brickbridgeconsulting.com/podcast)

Gil Roberts:

Welcome to the Podio solutions podcast episodes 2 season 1. I'm Gil Roberts with me today is our lead developer here at Brick Bridge , Alex Shull, principal consultant, Jarett Duker. This podcast is about the design and development on the CITRIX podio platform. Uh , that's it, podio.com po dio.com using this podcast to discuss your own experiences with podio as well as other interesting topics from the podio is developer community. You are a podio designer, developer working at an agency, small business or enterprise. You should immediately crush that subscribe button if you have already. Thank you so much for your support. Lastly, before we dive in today's topic, if you have a topic issue, solution problem or any other gap you would like to discuss on our , uh, for us to discuss on our show, we want to know he hit us on Facebook, linkedin, Twitter or send an email or podio message to podcast@brickbridgeconsulting.com . It's brick, B, R I C K Bridge, B R I D G E consulting.com.

Alex Shull:

That's it . Any questions to do with podio? Just bring it to us. We'd love to talk about podio.

Gil Roberts:

Yeah, absolutely. API's, any anything , uh, that you can think of. Globiflow procfu, uh , all the , the podio things. So today's topic , uh , as we just described on our first podcast would be how we build to impact pro, which is something that we've designed on as a wide scale solution. This is a two to three part series. The first two parts today , uh , being designed to morrow, or excuse me, on the next podcast will be the development. Uh, so what we're gonna do is we're going to tell a story about how we designed a national product. Didn't have a six figure budget and that was completely based on podio. Uh , we were able to bring an Alpha in about 90 days , uh , to a usable solution. Uh, Jared Duker was instrumental in getting that together as our principal consultant . So what we're gonna do is we're just gonna walk through the steps of how we did that Alpha in 90 days and how that experience was. So I'll start with you. Jared, what do you ,

Jarett Duker:

I think the first thing to recognize is that there are many gaps. Technologically speaking in a lot of the industries and our client came to us with a notion that they potentially could be stepping in and filling that gap and wanted to know if we had any ideas on a quick development cycle. We introduced them to podio.

Alex Shull:

I think it's important to realize also that the client in this case is not one that was strong technological competence. This is a client who knows what they're and how to do it, but they realize the solutions out there for getting their work done. We're just inadequate.

Jarett Duker:

Absolutely. And we recognized that there was a lot of potential here for finding clients that had strong technical competencies in their industry, but no real knowledge or understanding of how to create technical solutions. And so we started off with them from the very beginning. Uh , like the Bob's , what does it you say you'd say could do here? Yeah, I remember that. It was in December of 2016 into January, 2017 about a six week process that we went through. Speaking to each of the stakeholders at the company, beginning with upper management, looking at what sort of KPIs and performance metrics they want it to bring in to listening to the lowest end employees. Just gripe about the things they had to deal with on a day to day basis.

Alex Shull:

Did they have any documentation when you went in that helped you or did you have to discover the entire from scratch?

Gil Roberts:

That's a good point. Alex. I know Alex, you weren't a part of the team at this time so these are great questions. Yeah, go ahead.

Jarett Duker:

I'd have to say with every company I've engaged with it , unless they are a very, very large and well organized organization, which represents maybe 1% and even those are good chance, their documentation is out of date. The realities of what people do in their day to day job and how it's described in a training manual if it does exist, has very little correlation to each other. So no , um, generally speaking, most processes that are currently being performed in businesses all the way around the world are for the most part experiential, particularly if we're trying to capture a process that is a higher level employees process, their value to the company is the fact that they understand this. Um, and that's why they have job secured . They can't just be replaced instantly because no one knows exactly how to do what they do. They have an idea but not the details of it.

Gil Roberts:

It's almost like they're guardians of the key, right? Like they understand where the pieces should fit, where they shouldn't fit. And then I've noticed from just some of our consultations that you don't like this person gets hit by the proverbial bus. You know, that that organization actually has a, pretty large problem on their hands because somebody's not understanding how to fly the plane. Um, but you know, everybody knows their pieces underneath and I think that does cause some difficulty when we were working with this client.

Jarett Duker:

And that's the second step is even if people have strong competencies in the position that they currently hold, there's a almost guarantee that they're interacting with any number of other stakeholders in the organization who have the second key. And the third key, and while I understand again what that person does at a high level, they would be really lost in the details. So the very beginning was to come in and we had to be pretty pushy and demand that we don't just speak to upper management, we want to talk to the tech support rep, we want to talk to the secretary and get that holistic picture of operations to understand what it is that the industry really needs, what their industry really needs, not what they think it needs .

Gil Roberts:

And then you bring up a good point there is that trying to reach the actual end user of the product. And we've noticed through several of our large projects and even some of the small ones that like what management wants and even if there's a layer of middle management that the end user, the grunts down in the trenches, they have a very different view of the way things should be and let's be honest with you, the key to the success, right? If they don't implement it then then then we're going to have some problems within the software.

Alex Shull:

I think you speak to something that's interested in the software industry in general, which is the, the the shift, massive shifts we've seen away from the waterfall approach and towards the Agile more lean style develop development processes, procedures, and I think if you go into an organization where the executive level hasn't embraced the idea of those iterative delivery processes, then you're going to have some conflict with the idea that you need direct access to those users and so you really have to find people who are compatible with the value proposition. We bring that teams like ours can bring delivery solutions quickly and then iterating because if you get that feedback, if you get the solution in front of the user and you hear the feedback directly from the user, that's when you get a very tight, valuable iteration and you have to get that message through to the gatekeepers that, that action .

Gil Roberts:

And to add to that point , um, you have to understand what management sees the process is and then what people that actually get paid on a daily basis, what the process is.

Alex Shull:

Yeah, they have a view of it and then you go, you discover the reality. You have to suss out the real roles and responsibilities if you want to build software that delivers the value of the business.

Jarett Duker:

And that's why we started with a org chart for the organization. Even people who had no connection whatsoever to the processes we were modeling, we still wanted to know who they were and what they did so that we could make that decision and not have it pushed upon us. Because very frequently everyone looking out from their job, they don't see the whole picture. They see one to two points of connection away, but they may have no understanding of an entirely different process that has a key input somewhere along the value chain that they never even see because it's two points, two points of connection away. But it is absolutely critical if we don't get that entire view at the onset, it's a whole lot harder to iterate into it . We do lots and lots of iteration, but if there's a key deliverable that we don't identify at the beginning, it's a whole lot harder to include it after the fact was processes are only being designed once a software code is already being written, which is why discovery is so critical to delivering an effective solution on the podio platform.

Gil Roberts:

Yeah, you make a good point there because podio is flexible enough to do a lot of iterative development, but as pitfalls that we've seen, and we'll talk a little bit more about pitfalls later, but , uh, things that we've seen is where you get into too many iterations and you can run a budget off the track and now you going from an a nice healthy project margin , uh , for development agencies like ours, you guys know what we're talking about listening , uh , to a , uh , project margin that's much thinner or maybe break even or the worst, right ? Where you're actually bleeding out on a project that's never, never good.

Jarett Duker:

But that's also why podio is such a strong offering for industry level and a high scalability solutions because the fact of the matter is from the point that we agreed to take on the contract, to the point that we had active users, any system that was running the entire division of the organization was less than 90 days. Yeah . Including those initial conversations as we are evaluating the organization and trying to figure out what key metrics are necessary to build in.

Alex Shull:

And. Yeah. And then the real power is that for a very low investment, you start getting real feedback on, on a, on a model that you're developing for an application. So it's, you know , really embracing the pay as you go approach for building your , um, proof of concept and then your Alpha on this platform that has no commitment beyond the next month.

Gil Roberts:

Right? Right. Now we've, we've kicked around the office several times. You know, maybe a , a solution we build on podio may not live there forever, right? There's been some examples like investorfuse and some of these other ones out in the marketplace. That have used that as a, as a great sketchpad to prove the concept, get customers, get validation in the form of checks if we're looking at product level and to and to get the feedback , uh, and, then move on and kind of leave the nest.

Alex Shull:

Yeah know what we learned about your fundamental business and about the way data flows through your business won't change. Those are core lessons that you'll get out of the process that is describing, that will enable you to build that on podio or some other platform. Now we build and Podio as we do it rapidly and we know how to scale it now and so we can take that platform that provides very rapid terative capabilities to hone in on the customer needs and then we can actually deploy that solution as many times as you may not want to their clients.

Gil Roberts:

Let's take a quick moment to uh , this is all great, but let's take a quick moment to dive into the actual design of the product. Now, because of Ndas, we've signed with the client and, and some other things, we're not going to get into super specific stuff. What was just from a top level? Well , we got the process down . We got to talk to the stakeholders that we needed to talk to. What did the design look like from there?

Jarett Duker:

I think you've got two very critical things to remember whenever you are conceptualizing the podio design. Uh, the first one is you're always going to be intention between a data integrity and complexity. And what I mean by that is, yes, it's great to have every field on every form, but you have to remember that people are going to be looking at these forms five to 25 times or even more per day. And every time their eyes have to go over a field that's cognitive energy that they're putting in to decide that they do not need that field. And that doesn't sound like a big deal until you start to have four or five of these on a form and someone's going to see 10 times a day, all of a sudden you're wasting a lot of their mental energy. Um , something that is not essential or represents only 10% of the total of use cases. So when we really got into the meat of things, figuring out what is actually necessary and where it needs to live is the longest conversations that we're going to have. And management is always going to want absolutely everything everywhere, but they're not the ones who were using it every day. And if the user doesn't engage with and doesn't enjoy using the product, they're not going to,

Gil Roberts:

I I agree with that. I think that the way that podio is designed for some of the automations can help kind of ease both sides that management gets some of the other plethora of data that's needed. Um, the users get to get a little easiness to their job. You make a good point about having to read over things that are just not, not needed. Podio . So in that vertical scroll fashion. So you're almost always, we're very mindful of where the field is and its order.

Jarett Duker:

So the second thing to remember is podio is a relational database and that little relationship field can connect to any other relationship field inside of the organization. Uh , this is a , with great power comes great responsibility moment because very, very quickly you can begin drawing relationships between apps, between workspaces and the web can grow in one of two ways. It can be a neat, orderly, well planned web or it can look like a ball of yarn. And I've walked into a lot of organizations that had already been on the podium platform for while and I did get in home bills and I pull up their relationship map , uh , either through blogging flow or a third party tool and instantly I can identify why they are having chaos inside of their business.

Gil Roberts:

Yeah, there was a, there was a software solution that I worked on with you for , uh , the rei industry that had some issues with them jamming relationship fields. There were self referential stuff that, that was confusing with lead into loops. So it's, it's important to think about that design up front or you're gonna run into this solution , uh , issue , uh , not the solution that you're looking for. So, so a quick question here , uh , why , why do you think people go with the DIY? Why not, you know, what you know?

Jarett Duker:

Well, the whole point of the podio platform is that you can drag and drop. Someone with limited technical experience can create a professional level solution , uh , with a relatively small investment of time, energy, and money. But just because you can do something doesn't necessarily mean you should do it. And there's a lot of fundamental principles that come into data organization. And I'm not saying that you need to be a technical person to do this, but you do have to be a logical person. And any time you take a step you need to ask yourself, why am I taking this step? And if you can't come up with a compelling reason, you probably should not because true elegance inside of technical solutions comes from simplicity.

Alex Shull:

I think you were mentioning the relationship fields and how that can really turn into a , um, a , um, a problem if they're overused or used inappropriately. And I think that a lot of the lessons that we've learned using podio for these types of solutions , um , really reflects understanding the implications of some of those design choices. You have the choice to reference an existing item or use some sort of event based trigger to copied it into a new application. Well, why do you go one way or the other? And understanding those implications are very important because it leads to you either the separability of functions or leads to a stronger data integrity. It can impact scalability and you have to, you have to understand where you're going. You have to understand how those design choices create constraints and abilities.

Gil Roberts:

And we haven't even touched on something like compliance, right ? Especially if you're having some personal information that you're storing about your customers or clients like a CRM system. I mean there's, there's a lot to think about in design. I, you know, obviously we're a little biased, we're a agency that builds things on podio. Podio for our clients, both internal and product style solutions. But what are some of the other, pitfalls that kind of do it yourself crowd should be mindful of and kind of why they should come through an agency like those that listen to us as well as ourselves.

Jarett Duker:

Starting on a whiteboard I think is absolutely essential to draw out at the very least, your workspaces and your apps and what's going to connect to what and what is going to flow into what. And once you've decided on that, don't change it. At least not until you've completed your build , you go back and you can iterate on it later. But you should have a very firm notion of workflow firmly in mind before you even create your first workspace.

Alex Shull:

So the what do workspaces represent in your mind after you come through that discovery process as it relates to roles, responsibilities, departments, how do you use them to.

Jarett Duker:

there's two strong considerations. Let Gil set compliance. We have to, we have to talk about that. But that's really secondary. You need to think of them as a process. Containers, well, it can be business process . Yes. Um , uh , users should be able to set a task for themselves and complete that task inside of one workspace than less . There are countervailing considerations, but in most times when you, when you think I'm going to do x, x should be accomplished inside of a single work space , perhaps drawing elements from other workspaces, but I shouldn't have to change workspaces to accomplish any one individual task. So that entire process should be encapsulated from beginning to end in that one space. And generally speaking, you should pull any data you need into that space at the beginning of the process.

Alex Shull:

Yeah, and so oftentimes if you're talking about the enterprise viewpoint , you have companies that do business process management and they like to use a lot of UML and other diagrams really lay out their processes and you have these boxes that appear that are these discreet tasks. They, you don't have to know exactly what goes on inside the box, you know, what is the precondition and you know where it goes afterwards. And that's really what you're talking about. You're talking about one of those discrete tasks. Someone has the rights to go into a workspace and finish that task from beginning to end or else to a board the task, if you know, for some reason there is a reason to have a , you know, an error route. It some tasks to do or acquire .

Jarett Duker:

And that also opens up one of the major holes currently in podio programming , which is if someone has access to a workspace, there's minor permission levels. But for the most part, they have carp launch inside of that work space . And this leads to a major problem for a lot of organizations . It's not one we've ever not been able to overcome. A lot of times it's just psychological. Um, but we, you have to be very aware of the fact that anyone in that workspace is going to be able to manipulate data to a greater or lesser extent. You can control, right? A bit a read only access into specific apps. But for the most part, if someone's in that workspace, they're going to be able to manipulate and view the data inside of that workspace.

Gil Roberts:

The view is a, is a good point, especially if you do have some of that personal data in there or you know, you have different job roles. You know, maybe , uh , you work in an industry where the secretaries can't, um, review certain things. You know, that it has to be a program administrator. We run into that in the nonprofit side where that has to be separated up. Um , it can cause a lot of problems, especially on the design side. If you're not mindful of it.

Alex Shull:

I think that's one of they want to speak to is that we in the roadmap for Sassafras , just this is what we want to cover in a future episode, but in the roadmap for Sassafras is the definition and management of security rules that expand, uh , beyond the base security roles that are provided for podio. So who do you address that concern? As soon as we have that available, we'll let the community know about it. Yeah.

Jarett Duker:

And why this is such a big deal is a very minor thing. Like we don't want users to be able to view social security numbers. One field inside of a workspace that creates a problem could go so far as having to create entire duplicate work space without that field that passes information back and forth. So we added three layers of complexity to fixing single field issue. And this is what you would really need to avoid when you're doing your conceptualization because that is a compelling reason to break your workspace into separate processes before you get into full design and development.

Gil Roberts:

So really from the outset. And the reason why a lot of the DIY community sometimes gets it wrong or really wrong is because they're just not thinking all the way through the different layers of their process. Both, you know, how do I actually do my job? To what kind of fields on putting in there and then how sensitive those fields are , uh, to , to both the people that are using it and the overall design.

Alex Shull:

Yeah, I think that those two things are challenging to approach both iteratively and to make sure you're addressing all those concerns up front. So that first survey kind of sets the ground for what , what is the territory? Then you iterate over refining those boundaries, but you have to do both. You can't skip either.

Gil Roberts:

That's true.

Jarett Duker:

To get back to our example, this is what sets great , uh , design and discovery apart from , uh , kind of the baseline. Because take for example that social security number you have to know to ask that question and to dig down and find those specific fields because we may just put that on the podium form and it doesn't even come out until perhaps weeks in after launch that wait a second, don't want our secretaries seeing social security numbers inside of the system and now it necessitates a massive redesign or a layer of complete . Just slap a layer of complexity over it, which you can do to an extent, but you do too much and the entire product will be begin to collapse.

Alex Shull:

As you think about it is you like Gdpr and the international standards for privacy. You have a lot of these considerations, social security numbers , what we think about as the concern in the United States, but these , these are concerns that exist around the world.

Gil Roberts:

I think privacy just in general is a, is a huge concern even for stuff that my in the past not been considered sensitive. People are really taking notice of what kind of information they're sharing or , and then for businesses to take that information, they need to think about how they allow access to it. Well, let's talk a little bit about data flow. You touched on that. I want to take just a moment here to look at that and then I want to get a little bit more into the limitations.

Jarett Duker:

Podio is a wonderful platform for users that know how to use it. Um , because most of the time all of the functionality is built. Into is built by the people using it. It's small shops, it's a completely different world. Once you start designing industry level solutions and then hand it off to people who have not been trained and honestly don't care all that much , uh , but at the lowest end of the employee ladder. So there's a constant tension between creating compliance inside of podio builds and , uh, keeping it usable. Um, and one of the things, the concept that I use is dedicates inside of our design where someone cannot go further in their workflow until they've accomplished a specific task. Say acquiring a customer address, you may not send this file over to the sales team until you have an address. This is a , it's a hard line. It could just be accomplished with a required field, but most of the time we need to go beyond that because we didn't want to show it's a valid address that people aren't just typing whatever in.

Gil Roberts:

Yeah. I've noticed that in , in some of the old computer systems and software that I've run into that people are just, you know, Cordy and one, two, three, four because the field is required and they don't really use that as a part of their process are required. Fields aren't always great, right. From a design aspect because people will just try to bypass them by jamming junk in there.

Alex Shull:

Now, I've noticed the data gates that you implemented for some of our solutions, pick the form of just the audit that, you know , we might performing globiflow we might perform it as a function on the Sassafras event engine. um, is there any form of a d eity that a gain, other than just a pure audit of an item?

Jarett Duker:

Yes. Because it has to do with where a field lives are we putting, let's take that address field. Are we putting that on a prospect card that someone might have just had one conversation with the potential customer? Or are we putting that address field on a sales requisition for something that has had been handled two or three times and maybe has an hour plus investment?

Alex Shull:

So this is interesting to me because this goes back to the difference between looking at the entities, which are the items that we create in the podio applications and understanding how those map back to the processes that you were talking about in the first discovery because the data gate really is something that lives at the level of level of that process and a good span, multiple items across workspaces, theoretically, to know that you are in the correct state from the business process standpoint to move forward.

Jarett Duker:

Absolutely. And identifying those through, again, keep coming back to that initial discovery period will is what's going to keep your development costs under control.

Alex Shull:

Yeah. And again, going back to my enterprise architecture days and working in really large, complex corporate environments, I'm reminded of these business process management suites and workflow engines that are very, very expensive. But you know, something what we're doing with podio out of the gates in the lean process accomplishes all the same things. But when you do it from the outset, you get the benefit of that analysis. You get to build that into the processes that you're using to do , to design your application.

Gil Roberts:

Excellent. Uh , we touched on limitations a little bit earlier and I think this is an interesting discussion just that when we look at design side that the limitations of podio, globiflow and things like Zapier, cloud pipes, that kind of stuff, just that off the shelf suites that like you and I that are not full on developers. Uh , we , we can use these tools, but some of the limitations that you saw in design and how that, how that impacted impactpros uh, creation.

Jarett Duker:

We sat down and we did a thought experiment that says, could podio actually be used for a true enterprise level solution ? Something that may have 15,000 plus users in 5,000 plus managed copies of the same solution and have it looked at the tools that are currently on the market to , uh , interact , uh , natively with the Podio Api. And the answer is no. The philosophy behind a Zapier behind a globiflow is completely one off. You can build very complicated, really effective automations, but you cannot copy them. Uh , the, the very nature of the way that the building blocks are put together. Anytime you try to replicate, let's say I have a workspace with a flow in it, I want to copy that workspace. The flows in Globiflow , they're just not going to connect properly, which you can overcome when you won't. You know, I want to make five or six copies for a , uh , for my business. You can over , you hadn't take the time to sift through the flows, open each one, correct. Any errors that have snuck in, in the tokens, I want to do that 5,000 times is no longer sustainable.

Gil Roberts:

It's just not, not a viable way to do business.

Jarett Duker:

No. Pretty soon your transaction costs are going to be so high , um, that it's just going to collapse under its own complex.

Gil Roberts:

And the customers don't like it either because you don't have a solution to deploy , uh , copies . Especially with , from a product standpoint, it's even more severe. But even from an internal, I would say you have a, like we talked about in the first episode, a franchise model where each local store gets a copy of this software, you know , once or twice and you have you ever when your it guys sit there and make a copy for making this yourself and that may take him. I know when we first made our first copy , took her guy almost three days because it was so complex.

Jarett Duker:

The second thing is you're going to create a lot of attrition in your it department started asking people to do this.

Gil Roberts:

It's not, yeah, it's not super fun

Alex Shull:

There's another tech black aspect which is that we, we know that in the meantime some of the deployment tools have improved. But even if you were to go use , um , the podio deployment manager , is that from procfu?

Gil Roberts:

Yeah I think procfu has one coming out.

Alex Shull:

If you go to try to use the you at deployment manager will actually, it will make it easier for you to deploy a solution. But as, as of yet, if I'm not mistaken, they don't have a patching solution and in addition, every single deployment lives independently and so you don't get that same control over versioning and updates to the core logic . So yeah,

Gil Roberts:

I'm gonna cut you off right there cause I don't want to jump too far into next episode. Okay, fair enough. Cause we're gonna , we're gonna really dig into those a backhand technical things are starting to come to our shows time here. So I want, I want to spend about five minutes just taking a deep dive into controlling this discovery slash consulting slash design process. We, we call it discovery here. I think that's where we get the requirements. But you know, why is this the discovery portion of a project, especially for agencies, this applies to those that are small businesses and enterprises doing this internally. They might be listening as well. Why is it so critical in the podio design discovery phase?

Jarett Duker:

Because you're starting with a blank canvas. Anytime you create a podio account , you log in and there's absolutely nothing there and most people can look at a product and tell you what they don't like or what they like about it or what they would like to see or have added. It's a whole lot harder to go from an absolute blank slate to something. And most of the time this information we talked about subject matter experts that we're going to to uh, get the information that we need to build products for them. They don't either. They, they both do not see of all the way down the road to all the other touch points in other people's jobs or they're stuck inside their own box looking out. They know what they do. They've got strong technical competencies in what they do, but they don't think about it the same way that the CEO of the company thinks about in terms of complete process. The problem is the CEO doesn't know the details of what that employee is doing. So there's this into trinsic data schism that we have to overcome. And that's why discovery is so critical to talk to every member of the organization and get the details about what it is that they do.

Gil Roberts:

What do you think the number one way to approach, especially executive management, maybe middle level management to approach them and go, we need to talk to the end users, the employees. And they're like, well cause we've gotten this pushback before. Now we know our process. You don't need them. And I understand why because the manager or the executive is trying to shield their employee who's doing productive things for the business, right? And is not thinking about software development, which can be a distraction. But what's one of the reasons?

Jarett Duker:

Well we have to be realists and they are their employees and they're going to make those decisions. But from a development firm , be aware, this is where you're going to lose on cost. And so if you're working with an organization that's not going to give you complete transparency all the way down to their end users, build that into your project costs. I'm telling you right now, you weren't going to have more iterations on the back end because you have an incomplete picture on the front. Ultimately you can't do anything, but when you explain that to them and start bringing it to dollars and cents that you can invest, but that a day's time now at $13 an hour, whatever it happens to be for their employee, for them to sit down and explain things to you, or you can pay me $300 an hour to recode everything for you.

Alex Shull:

Yeah, like once or twice. Right. This goes back to the point, I made it very early in this broadcast that the client had bear some responsibility for being able to engage in this type of project. Successful. You have to have the right mindset. You have to understand the benefits of getting access to the user's getting exposure, interaction. Over those iterations. You can work with people who don't embrace it fully. They're just not gonna get the full benefits. And so it's really your job to convince them , um , that embracing this approach is going to pay off you.

Gil Roberts:

I think it's huge for podio development agencies like ours. But that I think this also applies to enterprise level where there's a it department or development department that is building these solutions that they too need to demand access cause they can be shut down as well.

Alex Shull:

it does, but oftentimes that goes back into a question of who's supporting the product and what is the, how do you measure the success of a product? Cause if you have a commercial software product, you're looking at the margins. But if you're have an enterprise product, you might just be looking at the value delivered. So you kind of evaluated differently. But, but no, I totally agree with you . You, you, you have to understand the benefits of, of having that iteration process. It's just that in , in the enterprise setting you might have different stakeholders, you might have a different relationship between the technical and the business so that that can vary by environment. But the lessons are the same.

Gil Roberts:

Excellent. Any , any last advice that we learned on this project? Um, over the course of 2017 which went into a Beta phase, and we're going to talk more about that on the next episode, but is there any last minute or last second advice for those that are in a small business setting? Maybe the owners working on this or maybe just a personal thing. I'll start with you Jared. Design .

Jarett Duker:

Bring someone else in to evaluate your processes. Even if it's your kids or anyone who's not you to take a look at it from a fresh eye and a fresh perspective and ask why are you doing these things? And there needs to be a compelling reason. Because so often we see this in business process where the way things are, the way things are, and I start digging in and I'll ask, start asking why. And it usually turns out that three employees ago, whoever was in this job did it this way and they just trained it and it just telephoned on down. Well, this is going to lead to bad designs inside of your solutions. There needs to be a compelling reason for any action you take.

Gil Roberts:

So to summarize, ask the question, why am I designing this way and get and get some fresh eyes? Absolutely. Alex

Alex Shull:

From the podio standpoint , um , coming through and seeing the development of a very complex solution like impact pro. I think one of the lessons that I learned from podio design standpoint is how vital it can be to have what we call it, an Admin workspace where you have administrative control over the solution, not at the deployment level but at the level of central control. Um, and that's in addition, we have admin workspaces for individual deployments to the clients. And so those are concepts that I think are very strong and they really helped us organize some of the work and manage , especially remoting Api integrations. Um, so those are some technical things that came about for the way we do have things running on Sassafras, but it's podio concepts that anyone could leverage.

Gil Roberts:

Yeah. So that that's, yeah, it's a good, again to summarize with you as well as to make sure to look at the process, not just itself, but how you control your process into the future.

Alex Shull:

If you need to support it, how do you, how can you automate supports ? Those are good questions to ask from .

Gil Roberts:

Fantastic. Well thanks again fellas . That wraps us up for this week. Next week we're going to have part two of this series we're going to dive into what we did during the Beta phase today was about the Alpha phase. The first 90 days we're going to dive into the Beta phase, which was uh, 14 months. So it was a really long project in which we got into a commercially viable products, which we call it CDP round here and how it's eventually gone on to sell in multiple states and is continuing to sell.

Speaker 1:

Do you have any questions or curiosities about impact pro? You can, you can go take a look at the product and impact pro. It's the letter M P A C T P R O . org this was done for a nonprofit. So it is a.org. So impact pro.org . Um, so we'll , we'll cover over the technical side. Alex will be leading our discussion. They are going to dig into the API. Some of the things we did to overcome some of the limitations we talked about today when we talked about scaling. As always we want you to participate in our podcast. We are always looking to be able to solve podio gaps. Uh , as we asked in our first episode, we are still seeking those are and we've gotten some responses. Please bring us your gaps, anything that's in podio or we're going to be looking through the user forums under the globiflow and Podio user forms and we want to be able to use that , uh , and talk about it in one of our shows. Maybe even have you on as a guest. So please , uh, you can reach us, Facebook, Twitter, linkedin, email and podio. Message , uh ,

Alex Shull:

Remember, to press subscribe.

Gil Roberts:

Yeah, always, always crush on and subscribed . By the way, we greatly appreciate that. That helps us out more than you know. So getting your gaps hit that subscribe button. And we'll talk to you next week. Thank you.